[JBoss JIRA] (JBIDE-19697) org.jboss.tools.runtime.ui.prefs mysteriously appears in Eclipse dir during JBDS BYOE installation
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19697?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-19697:
---------------------------------------
[~mickael_istria], can you help here?
Do you know how Oomph works?
You probably don't need to read this whole JIRA, this is a short summary for you:
During installation of JBoss Tools into Eclipse, the runtime detection preferences file (org.jboss.tools.runtime.ui.prefs) is copied into ECLIPSE_DIR/Contents/Eclipse/configuration/.settings/ . It seems that Oomph is doing this. But it happens even if I disable the Preference Recorder (see the screenshot above). Could that be a bug for Oomph? Or am I doing something wrong?
> org.jboss.tools.runtime.ui.prefs mysteriously appears in Eclipse dir during JBDS BYOE installation
> --------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19697
> URL: https://issues.jboss.org/browse/JBIDE-19697
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.3.0.Alpha2
> Reporter: Martin Malina
> Assignee: Snjezana Peco
> Attachments: preference-recorder.png
>
>
> When I install JBDs 9.0.0.Alpha2 B24 BYOE into new Eclipse Mars M6 and new workspace, during the installation, suddenly the runtime detection config appears inside my Eclipse isntall dir:
> {code}
> $ find Eclipse-runtime-test.app/ -name 'org.jboss.tools.runtime.*.prefs'
> Eclipse-runtime-test.app//Contents/Eclipse/configuration/.settings/org.jboss.tools.runtime.ui.prefs
> {code}
> This is inside the file:
> {code}
> $ find Eclipse-runtime-test.app/ -name 'org.jboss.tools.runtime.*.prefs'|xargs cat
> eclipse.preferences.version=1
> runtimePaths=<?xml version\="1.0" encoding\="UTF-8" standalone\="no"?>\n<runtimePaths version\="2">\n <runtimePath path\="/Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0" scanOnEveryStartup\="false" timestamp\="-1">\n <serverDefinitions>\n <serverDefinition description\="" enabled\="true" location\="/Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0" name\="JBoss EAP 6.3" type\="EAP" version\="6.3">\n <included/>\n </serverDefinition>\n </serverDefinitions>\n </runtimePath>\n</runtimePaths>\n
> {code}
> It contains /Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0 which I use regularly when testing server tooling. But how did this happen?
> I looked for the pref file before I started BYOE installation. Then a bit later, a few minutes into the installation, I checked again and the file is there now.
> Can somebody explain what's going on?
> Note: This happened to me yesterday and it surprised me, but I wasn't sure if it wasn't my mistake somehow. But Max preferred I try again, so I did. And it is happening again now.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19703) Offline script is unable to resolve dependencies (error grabbing Grapes)
by Radim Hopp (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19703?page=com.atlassian.jira.plugi... ]
Radim Hopp commented on JBIDE-19703:
------------------------------------
I tried with same versions as you. Still no success. I'll try it on MacOS (you tried it on mac, right?) to see if it will work there.
> Offline script is unable to resolve dependencies (error grabbing Grapes)
> ------------------------------------------------------------------------
>
> Key: JBIDE-19703
> URL: https://issues.jboss.org/browse/JBIDE-19703
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: project-examples
> Affects Versions: 4.3.0.Alpha2
> Environment: JBDS 9.0.0.Alpha2
> Reporter: Radim Hopp
> Assignee: Fred Bricon
> Fix For: 4.3.0.Beta1
>
>
> When user has empty .groovy/grapes, offline script is not working:
> {noformat}groovy "/home/rhopp/workspace-tests/.metadata/.plugins/org.jboss.tools.project.examples/offline/go_offline_3.0.0.Alpha2_v20150417_1854_B11.groovy" http://download.jboss.org/jbosstools/examples/4.3/project-examples-catego... http://download.jboss.org/jbosstools/examples/4.3/project-examples-shared... http://download.jboss.org/jbosstools/examples/4.3/project-examples-jbds90... http://download.jboss.org/gatein/quickstarts/jboss-portal-6.2/project-exa... -e |tee output
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
> General error during conversion: Error grabbing Grapes -- [download failed: org.jboss.logging#jboss-logging;3.1.2.GA!jboss-logging.jar]
> java.lang.RuntimeException: Error grabbing Grapes -- [download failed: org.jboss.logging#jboss-logging;3.1.2.GA!jboss-logging.jar]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77)
> at org.codehaus.groovy.reflection.CachedConstructor.doConstructorInvoke(CachedConstructor.java:71)
> at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrap.callConstructor(ConstructorSite.java:81)
> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:57)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:230)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:242)
> at groovy.grape.GrapeIvy.getDependencies(GrapeIvy.groovy:418)
> 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.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSite.invoke(PogoMetaMethodSite.java:166)
> at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:56)
> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
> at groovy.grape.GrapeIvy.resolve(GrapeIvy.groovy:563)
> at groovy.grape.GrapeIvy$resolve$1.callCurrent(Unknown Source)
> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:185)
> at groovy.grape.GrapeIvy.resolve(GrapeIvy.groovy:532)
> at groovy.grape.GrapeIvy$resolve$0.callCurrent(Unknown Source)
> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:49)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:177)
> at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:254)
> at groovy.grape.Grape.grab(Grape.java:163)
> at groovy.grape.GrabAnnotationTransformation.visit(GrabAnnotationTransformation.java:358)
> at org.codehaus.groovy.transform.ASTTransformationVisitor$3.call(ASTTransformationVisitor.java:319)
> at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:928)
> at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:590)
> at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:566)
> at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:543)
> at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:297)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:267)
> at groovy.lang.GroovyShell.parseClass(GroovyShell.java:692)
> at groovy.lang.GroovyShell.run(GroovyShell.java:521)
> at groovy.lang.GroovyShell.run(GroovyShell.java:511)
> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:650)
> at groovy.ui.GroovyMain.run(GroovyMain.java:381)
> at groovy.ui.GroovyMain.process(GroovyMain.java:367)
> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:126)
> at groovy.ui.GroovyMain.main(GroovyMain.java:106)
> 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.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:106)
> at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:128)
> 1 error
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19697) org.jboss.tools.runtime.ui.prefs mysteriously appears in Eclipse dir during JBDS BYOE installation
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19697?page=com.atlassian.jira.plugi... ]
Martin Malina edited comment on JBIDE-19697 at 4/30/15 5:11 AM:
----------------------------------------------------------------
So Radim Hopp came up with the idea that it could actually be Oomph that is doing this.
And it seems to be the case.
See the very first item of the Preference page of Preference Recorder:
!preference-recorder.png!
But even if I disable this in a brand new instance of Eclipse, it still happens - once I install JBT, the config appears there and after Eclipse restart, I am offered to add those runtimes :(
And I tried one more thing: I installed nightly build of JBoss Tools into Eclipse Mars M4 and in this case this doesn't happen - the config is not copied during the installation. So I think Oomph is to blame (it's not present in M4).
was (Author: mmalina):
So Radim Hopp came up with the idea that it could actually be Oomph that is doing this.
And it seems to be the case.
See the very first item of the Preference page of Preference Recorder:
!preference-recorder.png!
But even if I disable this in a brand new instance of Eclipse, it still happens - once I install JBT, the config appears there and after Eclipse restart, I am offered to add those runtimes :(
> org.jboss.tools.runtime.ui.prefs mysteriously appears in Eclipse dir during JBDS BYOE installation
> --------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19697
> URL: https://issues.jboss.org/browse/JBIDE-19697
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.3.0.Alpha2
> Reporter: Martin Malina
> Assignee: Snjezana Peco
> Attachments: preference-recorder.png
>
>
> When I install JBDs 9.0.0.Alpha2 B24 BYOE into new Eclipse Mars M6 and new workspace, during the installation, suddenly the runtime detection config appears inside my Eclipse isntall dir:
> {code}
> $ find Eclipse-runtime-test.app/ -name 'org.jboss.tools.runtime.*.prefs'
> Eclipse-runtime-test.app//Contents/Eclipse/configuration/.settings/org.jboss.tools.runtime.ui.prefs
> {code}
> This is inside the file:
> {code}
> $ find Eclipse-runtime-test.app/ -name 'org.jboss.tools.runtime.*.prefs'|xargs cat
> eclipse.preferences.version=1
> runtimePaths=<?xml version\="1.0" encoding\="UTF-8" standalone\="no"?>\n<runtimePaths version\="2">\n <runtimePath path\="/Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0" scanOnEveryStartup\="false" timestamp\="-1">\n <serverDefinitions>\n <serverDefinition description\="" enabled\="true" location\="/Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0" name\="JBoss EAP 6.3" type\="EAP" version\="6.3">\n <included/>\n </serverDefinition>\n </serverDefinitions>\n </runtimePath>\n</runtimePaths>\n
> {code}
> It contains /Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0 which I use regularly when testing server tooling. But how did this happen?
> I looked for the pref file before I started BYOE installation. Then a bit later, a few minutes into the installation, I checked again and the file is there now.
> Can somebody explain what's going on?
> Note: This happened to me yesterday and it surprised me, but I wasn't sure if it wasn't my mistake somehow. But Max preferred I try again, so I did. And it is happening again now.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19697) org.jboss.tools.runtime.ui.prefs mysteriously appears in Eclipse dir during JBDS BYOE installation
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19697?page=com.atlassian.jira.plugi... ]
Martin Malina updated JBIDE-19697:
----------------------------------
Attachment: preference-recorder.png
So Radim Hopp came up with the idea that it could actually be Oomph that is doing this.
And it seems to be the case.
See the very first item of the Preference page of Preference Recorder:
!preference-recorder.png!
But even if I disable this in a brand new instance of Eclipse, it still happens - once I install JBT, the config appears there and after Eclipse restart, I am offered to add those runtimes :(
> org.jboss.tools.runtime.ui.prefs mysteriously appears in Eclipse dir during JBDS BYOE installation
> --------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19697
> URL: https://issues.jboss.org/browse/JBIDE-19697
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.3.0.Alpha2
> Reporter: Martin Malina
> Assignee: Snjezana Peco
> Attachments: preference-recorder.png
>
>
> When I install JBDs 9.0.0.Alpha2 B24 BYOE into new Eclipse Mars M6 and new workspace, during the installation, suddenly the runtime detection config appears inside my Eclipse isntall dir:
> {code}
> $ find Eclipse-runtime-test.app/ -name 'org.jboss.tools.runtime.*.prefs'
> Eclipse-runtime-test.app//Contents/Eclipse/configuration/.settings/org.jboss.tools.runtime.ui.prefs
> {code}
> This is inside the file:
> {code}
> $ find Eclipse-runtime-test.app/ -name 'org.jboss.tools.runtime.*.prefs'|xargs cat
> eclipse.preferences.version=1
> runtimePaths=<?xml version\="1.0" encoding\="UTF-8" standalone\="no"?>\n<runtimePaths version\="2">\n <runtimePath path\="/Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0" scanOnEveryStartup\="false" timestamp\="-1">\n <serverDefinitions>\n <serverDefinition description\="" enabled\="true" location\="/Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0" name\="JBoss EAP 6.3" type\="EAP" version\="6.3">\n <included/>\n </serverDefinition>\n </serverDefinitions>\n </runtimePath>\n</runtimePaths>\n
> {code}
> It contains /Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0 which I use regularly when testing server tooling. But how did this happen?
> I looked for the pref file before I started BYOE installation. Then a bit later, a few minutes into the installation, I checked again and the file is there now.
> Can somebody explain what's going on?
> Note: This happened to me yesterday and it surprised me, but I wasn't sure if it wasn't my mistake somehow. But Max preferred I try again, so I did. And it is happening again now.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19741) jbosstools-javaee contains 141M of duplicate jars in its tests' projects and resources - can we minimize this?
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19741?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-19741:
---------------------------------------------
oh my eyes.
for what it is worth, if they are the binary equivalent git should be reusing them, but yeah it is still alot of overhead. Removing them in root wont remove them from history though.
> jbosstools-javaee contains 141M of duplicate jars in its tests' projects and resources - can we minimize this?
> --------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19741
> URL: https://issues.jboss.org/browse/JBIDE-19741
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdi, jsp/jsf/xml/html source editing, seam2
> Reporter: Nick Boldt
> Attachments: jars.in.javaee.list.of.dupes.with.counts.txt, jars.in.javaee.txt
>
>
> There are 141M of binaries in the jbosstools-javaee source tree.
> See attached files for details. Would it be possible to pull these jars from Maven instead of having as many as *19* copies of the same jar in the source repo?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19719) EasyImport of MobileHybrid project with Android SDK not configured results in errors - written to .log, but not communicated to the user via the UI
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19719?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-19719:
---------------------------------------------
Thanks.
I would still say it make sense to put a warning if possible. It seems very similar to your project be configured to compile with Java 7 but you only have Java 6 available. But for now at least not log something that is not actually blocking the user.
> EasyImport of MobileHybrid project with Android SDK not configured results in errors - written to .log, but not communicated to the user via the UI
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19719
> URL: https://issues.jboss.org/browse/JBIDE-19719
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: upstream
> Affects Versions: 4.3.0.Alpha2
> Reporter: Len DiMaggio
> Assignee: Gorkem Ercan
> Attachments: jbosstools-diagnostics-20150427143128.zip, jbosstools-diagnostics-20150428105107.zip
>
>
> This issue is related to JBIDE-19716
> Multiple errors are raised when a mobile hybrid project created in Central in JBoss Tools 4.3.0.alpha2 is exported and then imported from a directory using easy import.
> See attached .zip for the error file (logs, etc..)
> The error message logged is:
> eclipse.core.runtime.CoreException: Android SDK location is not defined
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19697) org.jboss.tools.runtime.ui.prefs mysteriously appears in Eclipse dir during JBDS BYOE installation
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19697?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-19697:
---------------------------------------
Thanks, Snjeza, but I still don't know at what point does it discover that there is another installation of Eclipse in another dir and get the config file from there and copy it over to the currently running Eclipse. Because as far as I see it, all of the above is only related to searching for the right path inside the current Eclipse, not looking for other installations of Eclipse.
But I will ask somebody else to read through this and perhaps they will get it :)
> org.jboss.tools.runtime.ui.prefs mysteriously appears in Eclipse dir during JBDS BYOE installation
> --------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19697
> URL: https://issues.jboss.org/browse/JBIDE-19697
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.3.0.Alpha2
> Reporter: Martin Malina
> Assignee: Snjezana Peco
>
> When I install JBDs 9.0.0.Alpha2 B24 BYOE into new Eclipse Mars M6 and new workspace, during the installation, suddenly the runtime detection config appears inside my Eclipse isntall dir:
> {code}
> $ find Eclipse-runtime-test.app/ -name 'org.jboss.tools.runtime.*.prefs'
> Eclipse-runtime-test.app//Contents/Eclipse/configuration/.settings/org.jboss.tools.runtime.ui.prefs
> {code}
> This is inside the file:
> {code}
> $ find Eclipse-runtime-test.app/ -name 'org.jboss.tools.runtime.*.prefs'|xargs cat
> eclipse.preferences.version=1
> runtimePaths=<?xml version\="1.0" encoding\="UTF-8" standalone\="no"?>\n<runtimePaths version\="2">\n <runtimePath path\="/Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0" scanOnEveryStartup\="false" timestamp\="-1">\n <serverDefinitions>\n <serverDefinition description\="" enabled\="true" location\="/Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0" name\="JBoss EAP 6.3" type\="EAP" version\="6.3">\n <included/>\n </serverDefinition>\n </serverDefinitions>\n </runtimePath>\n</runtimePaths>\n
> {code}
> It contains /Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0 which I use regularly when testing server tooling. But how did this happen?
> I looked for the pref file before I started BYOE installation. Then a bit later, a few minutes into the installation, I checked again and the file is there now.
> Can somebody explain what's going on?
> Note: This happened to me yesterday and it surprised me, but I wasn't sure if it wasn't my mistake somehow. But Max preferred I try again, so I did. And it is happening again now.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months