[JBoss JIRA] (JBDS-3240) JBDS 8 aka JBoss Central provide by default old EAP/WFK archetypes
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3240?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-3240:
--------------------------------
Component/s: central
> JBDS 8 aka JBoss Central provide by default old EAP/WFK archetypes
> ------------------------------------------------------------------
>
> Key: JBDS-3240
> URL: https://issues.jboss.org/browse/JBDS-3240
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: central
> Affects Versions: 8.0.0.GA
> Reporter: Marek Novotny
> Assignee: Fred Bricon
>
> JBDS 8 aka JBoss Central provide by default old EAP/WFK archetype and not the latest 6.3.0.GA/2.6.0.Final by default.
> For instance I click on HTML5 project in Start from Scratch in JBoss Central:
> it launches wizard dialog where the archetype is org.jboss.tools.example.html5:jboss-as-kitchensink-html5-mobile:1.0.4.Final-redhat-wfk-2 version
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
1 week, 2 days
[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, 2 weeks
[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
2 months, 2 weeks
[JBoss JIRA] Created: (JBDS-983) Console not showing up when staritng a EAP/SOA-P Instance
by Jim Tyrrell (JIRA)
Console not showing up when staritng a EAP/SOA-P Instance
---------------------------------------------------------
Key: JBDS-983
URL: https://jira.jboss.org/jira/browse/JBDS-983
Project: JBoss Developer Studio
Issue Type: Feature Request
Affects Versions: 3.0.0.M4
Reporter: Jim Tyrrell
For some reason starting a SOA-P instance by right clicking in the server view does not start/open the console for the output of the server as it is starting. For EAP and Seam projects this does not seem to be the case as often, but I think I have seen it. The current JBDS 3.0 M4 release does seem to not show the console unless I open the console via the Window -> Show View -> General -> Console and then I have to click an icon to enable the "Java Stack Trace Console". Once I have setup the console once as just noted even if I close it it will open as I expect. If I close JBDS and make sure that the console was not left open, I get the same behaviour when I try to right click on the SOA-P instance.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4 months
[JBoss JIRA] (JBIDE-19532) "Edit Server Runtime Environment" Dialog configuration validation is broken
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19532?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-19532:
-------------------------------------
I've been digging code for quite a while today but can't see any reason for the strange behavior. Even assuming your OS will return the underlying folder path rather than teh symlink path, it should still be validating it.
We may need to add this one to the list of things to verify together via a code-trace.
> "Edit Server Runtime Environment" Dialog configuration validation is broken
> ---------------------------------------------------------------------------
>
> Key: JBIDE-19532
> URL: https://issues.jboss.org/browse/JBIDE-19532
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.3.CR1
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Fix For: 4.3.0.Beta1
>
> Attachments: data-folder-config.png, Edit Server Runtime Environment _102.png, JBIDE-19532.png
>
>
> If I use "Browse" button for "Configuration base directory" and "Configuration file" validation has no complains, but result is broken Server that cannot start.
> {code}java.lang.IllegalStateException: basedir /home/eskimo/Java/wildfly-8.0.0.Final/configuration does not exist.
> at org.apache.tools.ant.DirectoryScanner.scan(DirectoryScanner.java:879)
> at org.jboss.ide.eclipse.as.core.extensions.descriptors.AntFileFilter.getIncludedFiles(AntFileFilter.java:40)
> at org.jboss.ide.eclipse.as.core.extensions.descriptors.XPathQuery.refresh(XPathQuery.java:133)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.XPathsPortsController.findPort(XPathsPortsController.java:80)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.XPathsPortsController.getPortOffset(XPathsPortsController.java:128)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.XPathsPortsController.getJBossWebPort(XPathsPortsController.java:110)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.XPathsPortsController.findPort(XPathsPortsController.java:58)
> at org.jboss.ide.eclipse.as.core.server.internal.JBossServer.findPort(JBossServer.java:209)
> at org.jboss.ide.eclipse.as.core.server.internal.JBossServer.getJBossWebPort(JBossServer.java:195)
> at org.jboss.ide.eclipse.as.core.extensions.polling.WebPortPoller.getURL(WebPortPoller.java:84)
> at org.jboss.ide.eclipse.as.core.extensions.polling.WebPortPoller.getCurrentStateSynchronous(WebPortPoller.java:155)
> at org.jboss.ide.eclipse.as.core.util.PollThreadUtils.isServerStarted(PollThreadUtils.java:227)
> at org.jboss.ide.eclipse.as.core.util.PollThreadUtils.isServerStarted(PollThreadUtils.java:213)
> at org.jboss.ide.eclipse.as.core.server.internal.launch.StandardLocalJBossStartLaunchDelegate.isServerStarted(StandardLocalJBossStartLaunchDelegate.java:68)
> at org.jboss.ide.eclipse.as.wtp.core.server.launch.AbstractStartJavaServerLaunchDelegate.preLaunchCheck(AbstractStartJavaServerLaunchDelegate.java:117)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.LocalJBossLaunchController.preLaunchCheck(LocalJBossLaunchController.java:119)
> at org.jboss.ide.eclipse.as.wtp.core.server.launch.ControllableServerLaunchConfiguration.preLaunchCheck(ControllableServerLaunchConfiguration.java:86)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:840)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731)
> at org.eclipse.wst.server.core.internal.Server.startImpl2(Server.java:3541)
> at org.eclipse.wst.server.core.internal.Server.startImpl(Server.java:3477)
> at org.eclipse.wst.server.core.internal.Server$StartJob.run(Server.java:367)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19637) Runtime download not working from New Server dialog
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19637?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-19637:
-------------------------------------
[~mmalina] We may need to try to set up a day when we can trace through several bugs at once. Let's schedule a day next week where we can make this happen. I'm sorry if I'll be causing you more work, but I simply don't have access to a Mac to do this debugging. =/
> Runtime download not working from New Server dialog
> ---------------------------------------------------
>
> Key: JBIDE-19637
> URL: https://issues.jboss.org/browse/JBIDE-19637
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.3.0.Alpha2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.0.Beta1
>
>
> When you go through Servers view -> New Server -> EAP 6.1 -> New Runtime and then click "Download and install runtime...", it won't do anything.
> If you go through Preferences -> Server -> Runtime Environments -> Add -> EAP 6.1+ and then click the Download button, it will work.
> This issue applies to both JBDS 8.1.0.GA and JBoss Tools 4.3.0.Alpha2 testing build, but I doubt we will be able to fix this for 4.2.x.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19738) Failed runtime download offers no error message
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19738?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-19738:
-------------------------------------
I'm not able to replicate this. My methodology is as follows:
1) enable internet ;)
2) window -> prefs -> jboss runtime detection
3) download
4) Select jboss fsw 6, press next
5) type in credentials
6) accept license, press next
7) disable internet
8) type in proper directories etc
9) perform finish
10) observe error "Host not found" shows up.
In general it seems that any exception or status object returned by InternalURLTransport.download(etc) is displayed as an error dialog by the download-runtimes logic.
So if your usecase isn't showing such an error dialog, the error must be occurring at a different time or for a different reason. But i can't imagine what those reasons are, and my traces through aren't providing any more information or obvious locations where errors are being ignored.
Any more info is definitely appreciated.
> Failed runtime download offers no error message
> -----------------------------------------------
>
> Key: JBIDE-19738
> URL: https://issues.jboss.org/browse/JBIDE-19738
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.2.3.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.0.Beta1
>
>
> While verifying JBIDE-19571 the runtime download failed and there was no error whatsoever. The download of FSW 6.0 almost started, but after a few seconds on the progress bar an error window showed up for a moment and then disappeared again and the download window was gone, too. After this, there was no error in the error view or the workspace log.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19742) Change color of B in batch Icon
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19742?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-19742:
-------------------------------------
!NewBatchIcon.png! looks much better IMHO. +1 to apply
> Change color of B in batch Icon
> -------------------------------
>
> Key: JBIDE-19742
> URL: https://issues.jboss.org/browse/JBIDE-19742
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: batch
> Affects Versions: 4.3.0.Alpha2
> Reporter: Fred Bricon
> Assignee: Daniel Azarov
> Priority: Minor
> Fix For: 4.3.0.Beta1
>
> Attachments: NewBatchIcon.png
>
>
> My brains keeps processing the red B of !https://raw.githubusercontent.com/jbosstools/jbosstools-javaee/03d08a6ffea565dca1207dc37d8ff1d213f4ab28/batch/plugins/org.jboss.tools.batch.ui/images/batch_icon16.png! as an error marker every time I see it.
> Could we please use another color? Blue or dark Green, nothing too bright.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19748) No error or message is displayed when a project namespace has no templates
by Jeff Cantrill (JIRA)
Jeff Cantrill created JBIDE-19748:
-------------------------------------
Summary: No error or message is displayed when a project namespace has no templates
Key: JBIDE-19748
URL: https://issues.jboss.org/browse/JBIDE-19748
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.3.0.Beta1
Reporter: Jeff Cantrill
Assignee: Jeff Cantrill
The following error when no templates are in a project namespace:
org.eclipse.core.runtime.AssertionFailedException: null argument:
at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:85)
at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:73)
at org.eclipse.jface.viewers.StructuredViewer.assertElementsNotNull(StructuredViewer.java:583)
at org.eclipse.jface.viewers.StructuredViewer.getRawChildren(StructuredViewer.java:1001)
at org.eclipse.jface.viewers.ColumnViewer.getRawChildren(ColumnViewer.java:700)
at org.eclipse.jface.viewers.AbstractTreeViewer.getRawChildren(AbstractTreeViewer.java:1349)
at org.eclipse.jface.viewers.TreeViewer.getRawChildren(TreeViewer.java:353)
at org.eclipse.jface.viewers.StructuredViewer.getFilteredChildren(StructuredViewer.java:906)
at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:617)
at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:815)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:791)
at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:611)
at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:762)
at org.eclipse.jface.viewers.AbstractTreeViewer.internalInitializeTree(AbstractTreeViewer.java:1541)
at org.eclipse.jface.viewers.TreeViewer.internalInitializeTree(TreeViewer.java:790)
at org.eclipse.jface.viewers.AbstractTreeViewer$5.run(AbstractTreeViewer.java:1525)
at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1462)
at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:366)
at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1423)
at org.eclipse.jface.viewers.AbstractTreeViewer.inputChanged(AbstractTreeViewer.java:1517)
at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:292)
at org.eclipse.jface.viewers.StructuredViewer.setInput(StructuredViewer.java:1701)
at org.jboss.tools.openshift.internal.ui.wizard.application.ResourcesDetailsPage.createTemplatesViewer(ResourcesDetailsPage.java:66)
at org.jboss.tools.openshift.internal.ui.wizard.application.ResourcesDetailsPage.doCreateControls(ResourcesDetailsPage.java:48)
at org.jboss.tools.openshift.internal.common.ui.wizard.AbstractOpenShiftWizardPage.createControl(AbstractOpenShiftWizardPage.java:70)
at org.eclipse.jface.wizard.Wizard.createPageControls(Wizard.java:175)
at org.eclipse.jface.wizard.WizardDialog.createPageControls(WizardDialog.java:705)
at org.eclipse.jface.wizard.WizardDialog.createContents(WizardDialog.java:597)
at org.eclipse.jface.window.Window.create(Window.java:430)
at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1096)
at org.jboss.tools.openshift.internal.common.ui.utils.WizardUtils.createWizardDialog(WizardUtils.java:53)
at org.jboss.tools.openshift.internal.common.ui.utils.WizardUtils.openWizard(WizardUtils.java:74)
at org.jboss.tools.openshift.internal.common.ui.utils.WizardUtils.openWizard(WizardUtils.java:67)
at org.jboss.tools.openshift.internal.ui.command.NewApplicationHandler.execute(NewApplicationHandler.java:36)
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.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
... 38 more
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19747) IllegalArgumentException when creating new batch job xml file
by Alexey Kazakov (JIRA)
Alexey Kazakov created JBIDE-19747:
--------------------------------------
Summary: IllegalArgumentException when creating new batch job xml file
Key: JBIDE-19747
URL: https://issues.jboss.org/browse/JBIDE-19747
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: batch
Affects Versions: 4.3.0.Beta1
Reporter: Alexey Kazakov
Assignee: Viacheslav Kabanovich
Fix For: 4.3.0.Beta1
1. File->New->Batch->Job XML File
2. Click on any project (root folder):
{code}
java.lang.IllegalArgumentException: Path must include project and resource name: /BatchTestProject
at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63)
at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:2069)
at org.eclipse.core.internal.resources.Container.getFolder(Container.java:201)
at org.jboss.tools.batch.ui.internal.wizard.NewJobXMLCreationWizard$WizardNewBeansXMLFileCreationPage.validatePage(NewJobXMLCreationWizard.java:367)
at org.eclipse.ui.dialogs.WizardNewFileCreationPage.handleEvent(WizardNewFileCreationPage.java:687)
at org.eclipse.ui.internal.ide.misc.ResourceAndContainerGroup.handleEvent(ResourceAndContainerGroup.java:369)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4477)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1322)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1346)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1327)
at org.eclipse.swt.widgets.Text.setText(Text.java:2560)
at org.eclipse.swt.widgets.Text.setText(Text.java:2486)
at org.eclipse.ui.internal.ide.misc.ContainerSelectionGroup.containerSelectionChanged(ContainerSelectionGroup.java:190)
at org.eclipse.ui.internal.ide.misc.ContainerSelectionGroup$1.selectionChanged(ContainerSelectionGroup.java:277)
at org.eclipse.jface.viewers.Viewer$2.run(Viewer.java:163)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:50)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:173)
at org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:160)
at org.eclipse.jface.viewers.StructuredViewer.updateSelection(StructuredViewer.java:2197)
at org.eclipse.jface.viewers.StructuredViewer.handleSelect(StructuredViewer.java:1228)
at org.eclipse.jface.viewers.StructuredViewer$4.widgetSelected(StructuredViewer.java:1257)
at org.eclipse.jface.util.OpenStrategy.fireSelectionEvent(OpenStrategy.java:242)
at org.eclipse.jface.util.OpenStrategy.access$4(OpenStrategy.java:236)
at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:408)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4477)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1322)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3815)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3425)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:827)
at org.eclipse.jface.window.Window.open(Window.java:803)
at org.eclipse.ui.internal.handlers.WizardHandler$New.executeHandler(WizardHandler.java:269)
at org.eclipse.ui.internal.handlers.WizardHandler.execute(WizardHandler.java:290)
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.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:247)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:229)
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:499)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:343)
at org.eclipse.ui.internal.actions.CommandAction.runWithEvent(CommandAction.java:160)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:595)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:511)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:420)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4477)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1322)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3815)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3425)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1112)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:993)
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:138)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19742) Change color of B in batch Icon
by Daniel Azarov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19742?page=com.atlassian.jira.plugi... ]
Daniel Azarov updated JBIDE-19742:
----------------------------------
Attachment: NewBatchIcon.png
> Change color of B in batch Icon
> -------------------------------
>
> Key: JBIDE-19742
> URL: https://issues.jboss.org/browse/JBIDE-19742
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: batch
> Affects Versions: 4.3.0.Alpha2
> Reporter: Fred Bricon
> Assignee: Daniel Azarov
> Priority: Minor
> Fix For: 4.3.0.Beta1
>
> Attachments: NewBatchIcon.png
>
>
> My brains keeps processing the red B of !https://raw.githubusercontent.com/jbosstools/jbosstools-javaee/03d08a6ffea565dca1207dc37d8ff1d213f4ab28/batch/plugins/org.jboss.tools.batch.ui/images/batch_icon16.png! as an error marker every time I see it.
> Could we please use another color? Blue or dark Green, nothing too bright.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19717) Visual (diagram) editor for JSR-352 batch job files.
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19717?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-19717:
-----------------------------------
Fix Version/s: 4.3.0.Beta1
(was: 4.3.x)
> Visual (diagram) editor for JSR-352 batch job files.
> ----------------------------------------------------
>
> Key: JBIDE-19717
> URL: https://issues.jboss.org/browse/JBIDE-19717
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: batch
> Affects Versions: 4.3.0.Alpha1
> Reporter: Tomáš Milata
> Assignee: Alexey Kazakov
> Labels: new_and_noteworthy
> Fix For: 4.3.0.Beta1
>
>
> A *visual* editor which allows users to *graphically draw* structure of a JSR-352 batch job xml file.
> Existing Sapphire model makes it easy to create a new Sapphire diagram editor that works together with the existing tree editor.
> While the existing tree editor is efficient for editing properties of *single element*, the diagram editor should serve as a useful *visualization* tool that helps with orientation in complex flow *strucures*.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19571) Add FSW to downloadable runtimes
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19571?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-19571:
-------------------------------------
[~mmalina] JBT will use a custom 'installer' which, rather than simply 'extracting' will run java -jar (the-file). This will run the installer.
One possible area of improvement which isn't there yet is that if the user selects a different installation folder during the installer, I could parse the installation log to get this value and then allow runtime detection to continue properly.
As of now, it will run the installer, and, if the user selects the same folder in the installer as he did in the jbt wizard, it will also locate the runtime / server after installation. If the user selects a different folder, though, then it won't.
Another possible area of improvement would be that we could ask that installers in the future allow for a sysprop that would set the default install location, and we could run java -jar {file} -Ddefault.install.dir={value_from_wizard}
But yeah... as of now... it could use some work.
> Add FSW to downloadable runtimes
> --------------------------------
>
> Key: JBIDE-19571
> URL: https://issues.jboss.org/browse/JBIDE-19571
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: server
> Affects Versions: 4.3.0.Alpha1
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.3.0.Beta1
>
>
> FSW 6.0 is not available in download runtimes
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19742) Change color of B in batch Icon
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19742?page=com.atlassian.jira.plugi... ]
Alexey Kazakov reassigned JBIDE-19742:
--------------------------------------
Fix Version/s: 4.3.0.Beta1
Assignee: Daniel Azarov
Sprint: Sprint #2 April 2015
OK. I see your point. Let's use another color.
> Change color of B in batch Icon
> -------------------------------
>
> Key: JBIDE-19742
> URL: https://issues.jboss.org/browse/JBIDE-19742
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: batch
> Affects Versions: 4.3.0.Alpha2
> Reporter: Fred Bricon
> Assignee: Daniel Azarov
> Priority: Minor
> Fix For: 4.3.0.Beta1
>
>
> My brains keeps processing the red B of !https://raw.githubusercontent.com/jbosstools/jbosstools-javaee/03d08a6ffea565dca1207dc37d8ff1d213f4ab28/batch/plugins/org.jboss.tools.batch.ui/images/batch_icon16.png! as an error marker every time I see it.
> Could we please use another color? Blue or dark Green, nothing too bright.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19741) jbosstools-javaee contains 141M of duplicate jars in its tests' projects and resources - can we minimize this?
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19741?page=com.atlassian.jira.plugi... ]
Alexey Kazakov commented on JBIDE-19741:
----------------------------------------
We definitely can minimize this.
The majority of these jars are in very old tests and we need to convert these tests to use maven for downloading the jars where it's possible.
Some of these jars are from dead code/plugins and we can remove them.
The rest is small custom jars which we need to for JAR handling testing. For example in CDI we pack some specific custom CDI beans in a JAR to make sure CDI tools load/handle them properly. But such jars are very small and it's not an issue.
> 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: Task
> Components: cdi, jsp/jsf/xml/html source editing, seam2
> Reporter: Nick Boldt
> Assignee: Alexey Kazakov
> Fix For: 4.3.0.Beta1
>
> 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, 12 months
[JBoss JIRA] (JBDS-3408) installer is trying to reach download.jboss.org for content
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3408?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-3408:
-----------------------------
Attachment: JBDS3408.install.jboss-devstudio-9.0.0.Beta1-v20150430-1113-B3095-installer-standalone.jar.log.txt
Steps to (not be able to) reproduce:
1. Download jboss-devstudio-9.0.0.Beta1-v20150430-1113-B3095-installer-standalone.jar
2. Disable network (verified by trying to ping google.com, eclipse.org, cnn.com):
{code}
$➔ ping google.com
ping: unknown host google.com
[12:57:52] nboldt@t540p-fc20-vm01:~/tmp
$➔ ping cnn.com
ping: unknown host cnn.com
[12:57:59] nboldt@t540p-fc20-vm01:~/tmp
$➔ ping eclipse.org
ping: unknown host eclipse.org
{code}
2. Install:
{code}java -jar -DTRACE=true jboss-devstudio-9.0.0.Beta1-v20150430-1113-B3095-installer-standalone.jar | tee JBDS3408.install.jboss-devstudio-9.0.0.Beta1-v20150430-1113-B3095-installer-standalone.jar.log.txt{code}
3. resulting log showing successful install & no references to the outside world:
[^JBDS3408.install.jboss-devstudio-9.0.0.Beta1-v20150430-1113-B3095-installer-standalone.jar.log.txt]
4. Note: On startup of JBDS, the new Central page showed an error (because Fred's new remotely hosted Central page could not be loaded) which further verifies installation works offline.
> installer is trying to reach download.jboss.org for content
> -----------------------------------------------------------
>
> Key: JBDS-3408
> URL: https://issues.jboss.org/browse/JBDS-3408
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 8.0.0.Alpha2
> Reporter: Max Rydahl Andersen
> Assignee: Nick Boldt
> Priority: Critical
> Fix For: 9.0.0.Beta1
>
> Attachments: JBDS3408.install.jboss-devstudio-9.0.0.Beta1-v20150430-1113-B3095-installer-standalone.jar.log.txt
>
>
> Running latest devstudio 9 installer I caught it in reaching out to download.jboss.org which it should have *zero* links/dependency on.
> My guess is there is an updatesite that have bad reference to download.jboss.org that we need fixing.
> See screenshot at https://www.dropbox.com/s/wkr30jlvdc7d8wu/Screenshot%202015-04-15%2013.11...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19342) Update code to cope with generics added to org.eclipse.core.runtime package API
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19342?page=com.atlassian.jira.plugi... ]
Denis Golovin edited comment on JBIDE-19342 at 4/30/15 12:36 PM:
-----------------------------------------------------------------
Building IAdapter hierarchy is not working for me, it fails with error explained here [451352|https://bugs.eclipse.org/bugs/show_bug.cgi?id=451352].
was (Author: dgolovin):
Building IAdapter hierarchy is not working for me fails with error explained here [451352|https://bugs.eclipse.org/bugs/show_bug.cgi?id=451352].
> Update code to cope with generics added to org.eclipse.core.runtime package API
> --------------------------------------------------------------------------------
>
> Key: JBIDE-19342
> URL: https://issues.jboss.org/browse/JBIDE-19342
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: aerogear-hybrid, archives, batch, bean-validation, birt, browsersim, cdi, cdi-extensions, central, common/jst/core, cordovasim, forge, hibernate, integration-platform, jmx, jsf, jsp/jsf/xml/html source editing
> Affects Versions: 4.3.0.Alpha2
> Reporter: Fred Bricon
> Priority: Minor
> Fix For: 4.3.x
>
>
> We need to detect and address any part of our code affected by generics added to the org.eclipse.core.runtime package API.
> From https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg11590.html :
> {quote}
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=442021
> Markus Keller wrote up an nice summary of what consumers should do to fix any warnings that may be caused by this change at https://bugs.eclipse.org/bugs/show_bug.cgi?id=442021#c25
> Here is a copy of the recommendations if you are going to compile against the latest version of org.eclipse.equinox.common:
> 1. In MANIFEST.MF, update your Require-Bundle: org.eclipse.core.runtime;bundle-version="[3.11.0,4.0.0)", or org.eclipse.equinox.common;bundle-version="[3.7.0,4.0.0)", or update your Import-Package: org.eclipse.core.runtime; version="[3.5,4.0)"
> 2. If your bundle re-exports one of these bundles, then you also have to make sure the minor version is incremented.
> 3. Remove unnecessary casts (Clean Up, or Problems view > Quick Fix > Select All)
> 4. Update implementations of IAdaptable#getAdapter(Class<T>), unless you override another implementation of that method that still uses the old signature.
> Typical change:
> Old:
> {code}
> public Object getAdapter(Class adapter) {
> if (ICompilationUnit.class.equals(adapter))
> return getCompilationUnit();
> return null;
> }
> {code}
> New:
> {code}
> public <T> T getAdapter(Class<T> adapter) {
> if (ICompilationUnit.class.equals(adapter))
> return adapter.cast(getCompilationUnit());
> return null;
> }
> {code}
> 5. Update implementations of IAdapterFactory
> Hint for 4. & 5.:
> - Open Type Hierarchy on IAdaptable, etc.
> - In the view menu, select a working set that contains your projects
> - In the methods list of the Type Hierarchy view, select the methods, and then click the first toolbar button (Lock View and Show Members in Hierarchy)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBDS-3345) Errors when starting FSW 6.0.0.GA from JBDS 8.0.2.GA with JDK 1.8
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBDS-3345?page=com.atlassian.jira.plugin.... ]
Rob Stryker commented on JBDS-3345:
-----------------------------------
> So if java -version shows JDK 7 then the server starts correctly JDK 8 then you will encounter problem which I reported
I am not able to replicate this at all.
my Path:
[rob@localhost eclipse]$ echo $PATH
/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/rob/.rvm/bin:/home/rob/.local/bin:/home/rob/bin:/home/rob/.rvm/bin:/home/rob/.local/bin:/home/rob/bin
My default java:
[rob@localhost eclipse]$ java -version
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
Eclipse is running with Java 8. I have configured my fsw6.0 runtime to use a java 7. It starts without error.
My launch command:
rob 7834 31.9 6.1 1725904 995624 pts/0 Sl+ 12:24 1:18 /home/rob/apps/java/jdk1.7.0_67/bin/java -Dprogram.name=JBossTools: JBoss Fuse Service Works 6.0 -server -Xms1024m -Xmx1024m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/home/rob/apps/jboss/fuse/fsw/installed/jboss-eap-6.1/standalone/log/boot.log -Dlogging.configuration=file:/home/rob/apps/jboss/fuse/fsw/installed/jboss-eap-6.1/standalone/configuration/logging.properties -Djboss.home.dir=/home/rob/apps/jboss/fuse/fsw/installed/jboss-eap-6.1 -Dorg.jboss.logmanager.nocolor=true -Djboss.bind.address.management=localhost -Dfile.encoding=UTF-8 -classpath /home/rob/apps/jboss/fuse/fsw/installed/jboss-eap-6.1/jboss-modules.jar org.jboss.modules.Main -mp /home/rob/apps/jboss/fuse/fsw/installed/jboss-eap-6.1/modules -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b localhost --server-config=standalone.xml -Djboss.server.base.dir=/home/rob/apps/jboss/fuse/fsw/installed/jboss-eap-6.1/standalone
I am not experiencing any error at all.
> Errors when starting FSW 6.0.0.GA from JBDS 8.0.2.GA with JDK 1.8
> -----------------------------------------------------------------
>
> Key: JBDS-3345
> URL: https://issues.jboss.org/browse/JBDS-3345
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: server
> Affects Versions: 8.0.2.GA
> Environment: Fedora 21 x86_64
> JBDS 8.0.2.GA with Oracle JDK 1.8.0_25 and Oracle JDK 1.7.0_71
> Reporter: Andrej Podhradsky
> Priority: Critical
> Attachments: compiler.png, console.png, errors.txt, error_log.txt, installed_jre.png, runtime_jre.png, server.log
>
>
> FSW 6.0.0.GA supports java 6 and 7, so if we want to run this server on JBDS 8 with jdk 8 we need to add another jdk to the JBDS, e.g. jdk 7. But this doesn't work, see errors in the attached file.
> Moreover, we are not able to stop the server from IDE, the process is still alive and we have to kill it manually.
> Note that this happens only when we install JBDS 8.0.2 with jdk 8, if we install it with jdk 7 the server works fine.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19732) Misleading error logged when a new hybrid mobile engine configured
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19732?page=com.atlassian.jira.plugi... ]
Len DiMaggio reassigned JBIDE-19732:
------------------------------------
Assignee: Gorkem Ercan
> Misleading error logged when a new hybrid mobile engine configured
> ------------------------------------------------------------------
>
> Key: JBIDE-19732
> URL: https://issues.jboss.org/browse/JBIDE-19732
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: aerogear-hybrid
> Affects Versions: 4.3.0.Alpha2
> Reporter: Len DiMaggio
> Assignee: Gorkem Ercan
> Priority: Minor
>
> There's no functional impact, but the error message is confusing.
> When a new mobile hybrid engine is configured, this error is logged:
> !ENTRY org.eclipse.thym.android.core 2 0 2015-04-28 14:38:54.071
> !MESSAGE Missing Android engine file /home/ldimaggi/.cordova/lib/android/cordova/3.7.1/framework/cordova-3.7.1.jar
> The file, however, is right where it belongs:
> ll /home/ldimaggi/.cordova/lib/android/cordova/3.7.1/framework/cordova-3.7.1.jar
> -rw-rw-r--. 1 ldimaggi ldimaggi 357355 Apr 28 14:38 /home/ldimaggi/.cordova/lib/android/cordova/3.7.1/framework/cordova-3.7.1.jar
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19731) Selecting "remove" before a hybrid mobile engine is created logs exception - no feeback is provided to users in the UI
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19731?page=com.atlassian.jira.plugi... ]
Len DiMaggio reassigned JBIDE-19731:
------------------------------------
Assignee: Gorkem Ercan
> Selecting "remove" before a hybrid mobile engine is created logs exception - no feeback is provided to users in the UI
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19731
> URL: https://issues.jboss.org/browse/JBIDE-19731
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: aerogear-hybrid
> Affects Versions: 4.3.0.Alpha2
> Reporter: Len DiMaggio
> Assignee: Gorkem Ercan
> Priority: Minor
>
> To recreate:
> * With no hybrid mobile engines defined
> * Preferences->Hybrid Mobile-> Engines
> * Click on "remove" and the exception is logged - no feedback is provided to the user in the UI
> !ENTRY org.eclipse.ui 4 0 2015-04-28 14:30:25.700
> !MESSAGE Unhandled event loop exception
> !STACK 0
> java.lang.ClassCastException: org.eclipse.thym.core.extensions.PlatformSupport cannot be cast to org.eclipse.thym.core.engine.HybridMobileEngine
> at org.eclipse.thym.ui.internal.engine.AvailableCordovaEnginesSection.handleRemoveEngine(AvailableCordovaEnginesSection.java:606)
> at org.eclipse.thym.ui.internal.engine.AvailableCordovaEnginesSection.access$4(AvailableCordovaEnginesSection.java:598)
> at org.eclipse.thym.ui.internal.engine.AvailableCordovaEnginesSection$5.handleEvent(AvailableCordovaEnginesSection.java:378)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4477)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1322)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3815)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3425)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:827)
> at org.eclipse.jface.window.Window.open(Window.java:803)
> at org.eclipse.ui.internal.dialogs.WorkbenchPreferenceDialog.open(WorkbenchPreferenceDialog.java:211)
> at org.eclipse.ui.internal.OpenPreferencesAction.run(OpenPreferencesAction.java:63)
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:473)
> at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:595)
> at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:511)
> at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:420)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4477)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1322)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3815)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3425)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1112)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:993)
> 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:138)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19741) jbosstools-javaee contains 141M of duplicate jars in its tests' projects and resources - can we minimize this?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19741?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-19741 at 4/30/15 11:20 AM:
--------------------------------------------------------------
Reason I suggest we de-dupe here is that the jbosstools-src.zip [1] is over 300M in size, and 141M of that is from javaee's included jars. (I could also just filter out the jars, but then the tests' sources won't match what's actually in github.)
[1] http://download.jboss.org/jbosstools/mars/snapshots/builds/jbosstools-bui...
I'm less concerned with cluttered history / large .git folder footprint than with making our published artifacts as small & efficient as possibru.
was (Author: nickboldt):
Reason I suggest we de-dupe here is that the jbosstools-src.zip is over 300M in size, and 141M of that is from javaee's included jars. (I could also just filter out the jars, but then the tests' sources won't match what's actually in github.)
I'm less concerned with cluttered history / large .git folder footprint than with making our published artifacts as small & efficient as possibru.
> 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, 12 months
[JBoss JIRA] (JBIDE-19741) jbosstools-javaee contains 141M of duplicate jars in its tests' projects and resources - can we minimize this?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19741?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-19741:
------------------------------------
Reason I suggest we de-dupe here is that the jbosstools-src.zip is over 300M in size, and 141M of that is from javaee's included jars. (I could also just filter out the jars, but then the tests' sources won't match what's actually in github.)
I'm less concerned with cluttered history / large .git folder footprint than with making our published artifacts as small & efficient as possibru.
> 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, 12 months
[JBoss JIRA] (JBIDE-19745) rename jbosstools-build-ci 4.3.x to jbosstools-4.3.x
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBIDE-19745:
-------------------------------------------
Summary: rename jbosstools-build-ci 4.3.x to jbosstools-4.3.x
Key: JBIDE-19745
URL: https://issues.jboss.org/browse/JBIDE-19745
Project: Tools (JBoss Tools)
Issue Type: Bug
Reporter: Max Rydahl Andersen
4.3.x is not following the convention all other repos has.
lets get it renamed to jbosstools-4.3.x to avoid confusion and document in readme on master that its a legacy branch only kept there for old builds.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19036) Cleanup Central TP
by Radim Hopp (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19036?page=com.atlassian.jira.plugi... ]
Radim Hopp closed JBIDE-19036.
------------------------------
> Cleanup Central TP
> ------------------
>
> Key: JBIDE-19036
> URL: https://issues.jboss.org/browse/JBIDE-19036
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: discovery
> Affects Versions: 4.2.1.Final
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Priority: Minor
> Fix For: 4.3.0.Alpha1
>
>
> It seems that the jbtcentral targetplatform contains some features that are already included in JBT and JBDS. Namely:
> * org.jboss.tools.forge.feature.feature.group
> * org.jboss.tools.forge.m2e.feature.feature.group
> So those features should probably trimmed out of the target platform.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19704) Visual part of Visual/Source tab is empty for HTML page when JSF support enabled
by Vlado Pakan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19704?page=com.atlassian.jira.plugi... ]
Vlado Pakan commented on JBIDE-19704:
-------------------------------------
I think simple pages should be displayed correctly and we should not confuse users with different rendering in Visual part of Visual/Source tab of VPE and Visual tab of VPE.
> Visual part of Visual/Source tab is empty for HTML page when JSF support enabled
> --------------------------------------------------------------------------------
>
> Key: JBIDE-19704
> URL: https://issues.jboss.org/browse/JBIDE-19704
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: visual-page-editor-core
> Affects Versions: 4.3.0.Alpha2
> Environment: Fedora 19 64bit, JBDS 9.0.0.Alpha2-v20150421-1151-B25, Oracle JDK 1.7
> Reporter: Vlado Pakan
> Assignee: Ilya Buziuk
>
> 1. Set Visual Editor to use JSF support
> 2. Create simple HTML page like this and open it in VPE editor
> {code:html}
> <!DOCTYPE html>
> <html>
> <body>
> <h1>test heading</h1>
> </body>
> </html>
> {code}
> ERROR: Visual part of Visual/Source tab of VPE is empty.
> Visual tab of VPE renders page properly.
> When HTML support is enabled it works fine.
> I'm not sure if this is issue or expected behavior so if it's not an issue just mark it as won't fix please.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19743) Execution of criteria query shows <null> result
by Jiri Peterka (JIRA)
Jiri Peterka created JBIDE-19743:
------------------------------------
Summary: Execution of criteria query shows <null> result
Key: JBIDE-19743
URL: https://issues.jboss.org/browse/JBIDE-19743
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: hibernate
Affects Versions: 4.3.0.Beta1
Environment: JBDS 9.0.0.Beta1 - nightly 20150430, L64
Reporter: Jiri Peterka
Priority: Blocker
Fix For: 4.3.0.Beta1
There is null result after executing Criteria query:
{code}
!ENTRY org.jboss.tools.hibernate.runtime.common 4 0 2015-04-30 15:16:16.562
!MESSAGE org.hibernate.impl.CriteriaImpl.setMaxResults()
!STACK 0
java.lang.NoSuchMethodException: org.hibernate.impl.CriteriaImpl.setMaxResults()
at java.lang.Class.getMethod(Class.java:1773)
at org.jboss.tools.hibernate.runtime.common.Util.invokeMethod(Util.java:39)
at org.jboss.tools.hibernate.runtime.common.AbstractCriteriaFacade.list(AbstractCriteriaFacade.java:39)
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:483)
at bsh.Reflect.invokeMethod(Unknown Source)
at bsh.Reflect.invokeObjectMethod(Unknown Source)
at bsh.BSHPrimarySuffix.doName(Unknown Source)
at bsh.BSHPrimarySuffix.doSuffix(Unknown Source)
at bsh.BSHPrimaryExpression.eval(Unknown Source)
at bsh.BSHPrimaryExpression.eval(Unknown Source)
at bsh.Interpreter.eval(Unknown Source)
at bsh.Interpreter.eval(Unknown Source)
at bsh.Interpreter.eval(Unknown Source)
at org.hibernate.eclipse.console.common.JavaPage.setSession(JavaPage.java:73)
at org.hibernate.eclipse.console.common.HibernateExtension$3.execute(HibernateExtension.java:127)
at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
at org.hibernate.eclipse.console.common.HibernateExtension.execute(HibernateExtension.java:189)
at org.hibernate.eclipse.console.common.HibernateExtension.executeCriteriaQuery(HibernateExtension.java:123)
at org.hibernate.console.ConsoleConfiguration.executeBSHQuery(ConsoleConfiguration.java:313)
at org.hibernate.eclipse.criteriaeditor.CriteriaEditor.executeQuery(CriteriaEditor.java:142)
at org.hibernate.eclipse.console.actions.ExecuteQueryAction.execute(ExecuteQueryAction.java:82)
at org.hibernate.eclipse.console.actions.ExecuteQueryAction.run(ExecuteQueryAction.java:55)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:473)
at org.hibernate.eclipse.console.actions.ExecuteQueryAction.runWithEvent(ExecuteQueryAction.java:59)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:595)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:511)
at org.eclipse.jface.action.ActionContributionItem$6.handleEvent(ActionContributionItem.java:462)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4477)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1322)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1346)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1331)
at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1116)
at org.jboss.reddeer.core.handler.WidgetHandler$4.run(WidgetHandler.java:332)
at org.jboss.reddeer.core.util.Display$VoidResultRunnable.run(Display.java:193)
at org.jboss.reddeer.core.util.Display$VoidResultRunnable.run(Display.java:1)
at org.jboss.reddeer.core.util.Display$ErrorHandlingRunnable.run(Display.java:159)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3790)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3428)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1112)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:993)
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:138)
at org.jboss.reddeer.eclipse.core.UITestApplication.start(UITestApplication.java:47)
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:483)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19697) org.jboss.tools.runtime.ui.prefs mysteriously appears in Eclipse dir during JBDS BYOE installation
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19697?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-19697:
----------------------------------------
The preference in oomph are probably not stored in the regular preference format, so looking for the file may not be enough.
There are 2 parts of Oomph: recording and storing preferences, and applying them to a new instance. Disabling the preference recorder only covers the first part. I don't know whether the part about restoring preferences can be controlled.
> 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, 12 months
[JBoss JIRA] (JBIDE-19463) Cannot connect to remote server in JMX Navigator
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19463?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-19463:
---------------------------------------
I just came across this today when testing EAP 6.4 - this was JBDS 8.1. But just wanted to let you know that it's still relevant ;)
> Cannot connect to remote server in JMX Navigator
> ------------------------------------------------
>
> Key: JBIDE-19463
> URL: https://issues.jboss.org/browse/JBIDE-19463
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jmx
> Affects Versions: 4.2.3.CR1, 4.3.0.Alpha1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.0.Beta1
>
>
> When you start a remote EAP 6.3 server with management enabled and set up and then want to connect in JMX Navigator, it does not work - double clicking the connection will not do anything and when you right-click, there is no Connect item.
> For local servers this works fine - there is a Connect item when you right-click the server in JMX Navigator.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19463) Cannot connect to remote server in JMX Navigator
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19463?page=com.atlassian.jira.plugi... ]
Martin Malina updated JBIDE-19463:
----------------------------------
Fix Version/s: 4.3.0.Beta1
> Cannot connect to remote server in JMX Navigator
> ------------------------------------------------
>
> Key: JBIDE-19463
> URL: https://issues.jboss.org/browse/JBIDE-19463
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jmx
> Affects Versions: 4.2.3.CR1, 4.3.0.Alpha1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.0.Beta1
>
>
> When you start a remote EAP 6.3 server with management enabled and set up and then want to connect in JMX Navigator, it does not work - double clicking the connection will not do anything and when you right-click, there is no Connect item.
> For local servers this works fine - there is a Connect item when you right-click the server in JMX Navigator.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19742) Change color of B in batch Icon
by Fred Bricon (JIRA)
Fred Bricon created JBIDE-19742:
-----------------------------------
Summary: Change color of B in batch Icon
Key: JBIDE-19742
URL: https://issues.jboss.org/browse/JBIDE-19742
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: batch
Affects Versions: 4.3.0.Alpha2
Reporter: Fred Bricon
Priority: Minor
My brains keeps processing the red B of !https://raw.githubusercontent.com/jbosstools/jbosstools-javaee/03d08a6ffea565dca1207dc37d8ff1d213f4ab28/batch/plugins/org.jboss.tools.batch.ui/images/batch_icon16.png! as an error marker every time I see it.
Could we please use another color? Blue or dark Green, nothing too bright.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19736) Update template list page to get 'openshift' templates and group accordingly
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19736?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-19736:
------------------------------------------
[~jcantrill] can you please add steps so that QE can reproduce and verify this?
> Update template list page to get 'openshift' templates and group accordingly
> ----------------------------------------------------------------------------
>
> Key: JBIDE-19736
> URL: https://issues.jboss.org/browse/JBIDE-19736
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: openshift
> Affects Versions: 4.3.0.Beta1
> Reporter: Jeff Cantrill
> Assignee: Jeff Cantrill
> Fix For: 4.3.0.Beta1
>
>
> When creating a template, a user should be able to choose from their project templates and those that are part of the configured (openshift) namespace. Update The template list page get templates from openshift namespace and to group templates under an appropriate folder (project or openshift)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months
[JBoss JIRA] (JBIDE-19717) Visual (diagram) editor for JSR-352 batch job files.
by Tomáš Milata (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19717?page=com.atlassian.jira.plugi... ]
Tomáš Milata commented on JBIDE-19717:
--------------------------------------
Pull request added.
> Visual (diagram) editor for JSR-352 batch job files.
> ----------------------------------------------------
>
> Key: JBIDE-19717
> URL: https://issues.jboss.org/browse/JBIDE-19717
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: batch
> Affects Versions: 4.3.0.Alpha1
> Reporter: Tomáš Milata
> Assignee: Alexey Kazakov
> Labels: new_and_noteworthy
> Fix For: 4.3.x
>
>
> A *visual* editor which allows users to *graphically draw* structure of a JSR-352 batch job xml file.
> Existing Sapphire model makes it easy to create a new Sapphire diagram editor that works together with the existing tree editor.
> While the existing tree editor is efficient for editing properties of *single element*, the diagram editor should serve as a useful *visualization* tool that helps with orientation in complex flow *strucures*.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 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:
---------------------------------------
[~mickael_istria], there are two things:
1. My ~/.eclipse does not contain this particular prefs file (org.jboss.tools.runtime.ui.prefs), so it would have to be some metadata saying it needs to be copied from somewhere else
2. "that has Oomph enabled" - didn't I disable it by unchecking "Enabled" for Preference Recorder? Because I couldn't find any other preference to disable Oomph.
...
OK, now I deleted ~/.eclipse and started a new instance of Eclipse Mars M6 and now the runtimePaths property (from the screenshot above) is gone. So it seems it was really stored in ~/.eclipse (but not the prefs file itself).
And once I installed JBoss Tools, the preferences file (org.jboss.tools.runtime.ui.prefs) is still not present inside my running eclipse instance.
So it all seems to make sense except the one thing - 2. - don't you agree that unchecking "Enabled" should disable this functionality?
> 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, 12 months
[JBoss JIRA] (JBIDE-18968) IllegalArgumentException: "Argument not valid" occurs every time central is opened
by Radim Hopp (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18968?page=com.atlassian.jira.plugi... ]
Radim Hopp closed JBIDE-18968.
------------------------------
This issue is not yet fixed in Alpha2 (the fix is present in eclipse 4.5M7 -> JBT Beta2).
But still, I am closing this one, because Central will be HTML5 in Beta2 and this issue will be out of date. And moreover the same issue is discussed for example in JBIDE-19270.
> IllegalArgumentException: "Argument not valid" occurs every time central is opened
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-18968
> URL: https://issues.jboss.org/browse/JBIDE-18968
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central, upstream
> Affects Versions: 4.2.1.Final
> Reporter: Denis Golovin
> Assignee: Snjezana Peco
> Fix For: 4.3.0.Alpha2
>
>
> {code}java.lang.IllegalArgumentException: Argument not valid
> at org.eclipse.swt.SWT.error(SWT.java:4422)
> at org.eclipse.swt.SWT.error(SWT.java:4356)
> at org.eclipse.swt.SWT.error(SWT.java:4327)
> at org.eclipse.swt.graphics.Image.init(Image.java:1294)
> at org.eclipse.swt.graphics.Image.<init>(Image.java:200)
> at org.eclipse.ui.forms.widgets.Section.onPaint(Section.java:344)
> at org.eclipse.ui.forms.widgets.ExpandableComposite$1.paintControl(ExpandableComposite.java:561)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:230)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4454)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1397)
> at org.eclipse.swt.widgets.Control.gtk_draw(Control.java:3174)
> at org.eclipse.swt.widgets.Canvas.gtk_draw(Canvas.java:171)
> at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2060)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:5513)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:4668)
> at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
> at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:9106)
> at org.eclipse.swt.widgets.Display.eventProc(Display.java:1253)
> at org.eclipse.swt.internal.gtk.OS._gdk_window_process_all_updates(Native Method)
> at org.eclipse.swt.internal.gtk.OS.gdk_window_process_all_updates(OS.java:5946)
> at org.eclipse.swt.widgets.Display.update(Display.java:4621)
> at org.eclipse.swt.widgets.Display.runDeferredLayouts(Display.java:3825)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3396)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 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:
------------------------------------
So this looks like Linux issue. Script was ok on Mac.
> 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, 12 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 updated JBIDE-19703:
-------------------------------
Environment: JBDS 9.0.0.Alpha2, Linux (Fedora 21, Mint) (was: JBDS 9.0.0.Alpha2)
> 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, Linux (Fedora 21, Mint)
> 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, 12 months
[JBoss JIRA] (JBIDE-19697) org.jboss.tools.runtime.ui.prefs mysteriously appears in Eclipse dir during JBDS BYOE installation
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19697?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-19697:
----------------------------------------
I believe Oomph records your preferences in the $HOME/.eclipse folder. Once they are recorded, every new installation of the IDE that has Oomph enabled will copy those preferences in your new installation.
> 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, 12 months
[JBoss JIRA] (JBIDE-19607) Offline quickstarts not working - Could not calculate build plan
by Radim Hopp (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19607?page=com.atlassian.jira.plugi... ]
Radim Hopp commented on JBIDE-19607:
------------------------------------
Verification blocked by JBIDE-19703.
> Offline quickstarts not working - Could not calculate build plan
> ----------------------------------------------------------------
>
> Key: JBIDE-19607
> URL: https://issues.jboss.org/browse/JBIDE-19607
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central, project-examples
> Affects Versions: 4.3.0.Alpha2
> Environment: JBDS 9.0.0 nightly build Alpha2-v20150414-2227-B2953
> Reporter: Radim Hopp
> Assignee: Fred Bricon
> Fix For: 4.3.0.Alpha2
>
>
> After running offline script and configuring JBDS to use that (without internet connectivity) I'm unable to import any of quickstarts. Some (as HTML5 project archetype for example) throw error into error log right after wizard startup:
> {noformat:title=Could not resolve artifact org.wildfly.archetype:wildfly-html5-mobile-archetype:pom:8.2.0.Final}
> org.eclipse.core.runtime.CoreException: Could not resolve artifact org.wildfly.archetype:wildfly-html5-mobile-archetype:pom:8.2.0.Final
> at org.eclipse.m2e.core.internal.embedder.MavenImpl$5.call(MavenImpl.java:776)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl$5.call(MavenImpl.java:1)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl.resolve(MavenImpl.java:743)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl.resolve(MavenImpl.java:720)
> at org.jboss.tools.maven.project.examples.wizard.ArchetypeExamplesWizardPage.downloadArchetype(ArchetypeExamplesWizardPage.java:262)
> at org.jboss.tools.maven.project.examples.wizard.ArchetypeExamplesWizardPage.access$4(ArchetypeExamplesWizardPage.java:252)
> at org.jboss.tools.maven.project.examples.wizard.ArchetypeExamplesWizardPage$3.run(ArchetypeExamplesWizardPage.java:206)
> at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:463)
> at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:371)
> at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:1002)
> at org.jboss.tools.maven.project.examples.wizard.ArchetypeExamplesWizardPage.getRequiredProperties(ArchetypeExamplesWizardPage.java:191)
> at org.jboss.tools.maven.project.examples.wizard.ArchetypeExamplesWizardPage.initializeArchetype(ArchetypeExamplesWizardPage.java:140)
> at org.jboss.tools.maven.project.examples.wizard.ArchetypeExamplesWizardPage.createControl(ArchetypeExamplesWizardPage.java:113)
> at org.eclipse.jface.wizard.Wizard.createPageControls(Wizard.java:175)
> at org.eclipse.jface.wizard.WizardDialog.createPageControls(WizardDialog.java:705)
> at org.eclipse.jface.wizard.WizardDialog.createContents(WizardDialog.java:597)
> at org.eclipse.jface.window.Window.create(Window.java:430)
> at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1096)
> at org.eclipse.jface.window.Window.open(Window.java:792)
> at org.jboss.tools.central.editors.GettingStartedPage.openWizard(GettingStartedPage.java:700)
> at org.jboss.tools.central.editors.GettingStartedPage.access$14(GettingStartedPage.java:685)
> at org.jboss.tools.central.editors.GettingStartedPage$7.linkActivated(GettingStartedPage.java:639)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.handleActivate(AbstractHyperlink.java:233)
> at org.eclipse.ui.forms.widgets.ImageHyperlink.handleActivate(ImageHyperlink.java:201)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.handleMouseUp(AbstractHyperlink.java:327)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.access$2(AbstractHyperlink.java:311)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink$4.handleEvent(AbstractHyperlink.java:125)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4477)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1322)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3815)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3425)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1112)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:993)
> 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:138)
> 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:483)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
> Contains: Failure to transfer org.wildfly.archetype:wildfly-html5-mobile-archetype:pom:8.2.0.Final from https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced. Original error: Could not transfer artifact org.wildfly.archetype:wildfly-html5-mobile-archetype:pom:8.2.0.Final from/to central (https://repo.maven.apache.org/maven2): repo.maven.apache.org: unknown error
> org.eclipse.aether.transfer.ArtifactTransferException: Failure to transfer org.wildfly.archetype:wildfly-html5-mobile-archetype:pom:8.2.0.Final from https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced. Original error: Could not transfer artifact org.wildfly.archetype:wildfly-html5-mobile-archetype:pom:8.2.0.Final from/to central (https://repo.maven.apache.org/maven2): repo.maven.apache.org: unknown error
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.newException(DefaultUpdateCheckManager.java:238)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkArtifact(DefaultUpdateCheckManager.java:206)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.gatherDownloads(DefaultArtifactResolver.java:585)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:503)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl$5.call(MavenImpl.java:753)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl$5.call(MavenImpl.java:1)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl.resolve(MavenImpl.java:743)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl.resolve(MavenImpl.java:720)
> at org.jboss.tools.maven.project.examples.wizard.ArchetypeExamplesWizardPage.downloadArchetype(ArchetypeExamplesWizardPage.java:262)
> at org.jboss.tools.maven.project.examples.wizard.ArchetypeExamplesWizardPage.access$4(ArchetypeExamplesWizardPage.java:252)
> at org.jboss.tools.maven.project.examples.wizard.ArchetypeExamplesWizardPage$3.run(ArchetypeExamplesWizardPage.java:206)
> at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:463)
> at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:371)
> at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:1002)
> at org.jboss.tools.maven.project.examples.wizard.ArchetypeExamplesWizardPage.getRequiredProperties(ArchetypeExamplesWizardPage.java:191)
> at org.jboss.tools.maven.project.examples.wizard.ArchetypeExamplesWizardPage.initializeArchetype(ArchetypeExamplesWizardPage.java:140)
> at org.jboss.tools.maven.project.examples.wizard.ArchetypeExamplesWizardPage.createControl(ArchetypeExamplesWizardPage.java:113)
> at org.eclipse.jface.wizard.Wizard.createPageControls(Wizard.java:175)
> at org.eclipse.jface.wizard.WizardDialog.createPageControls(WizardDialog.java:705)
> at org.eclipse.jface.wizard.WizardDialog.createContents(WizardDialog.java:597)
> at org.eclipse.jface.window.Window.create(Window.java:430)
> at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1096)
> at org.eclipse.jface.window.Window.open(Window.java:792)
> at org.jboss.tools.central.editors.GettingStartedPage.openWizard(GettingStartedPage.java:700)
> at org.jboss.tools.central.editors.GettingStartedPage.access$14(GettingStartedPage.java:685)
> at org.jboss.tools.central.editors.GettingStartedPage$7.linkActivated(GettingStartedPage.java:639)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.handleActivate(AbstractHyperlink.java:233)
> at org.eclipse.ui.forms.widgets.ImageHyperlink.handleActivate(ImageHyperlink.java:201)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.handleMouseUp(AbstractHyperlink.java:327)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.access$2(AbstractHyperlink.java:311)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink$4.handleEvent(AbstractHyperlink.java:125)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4477)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1322)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3815)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3425)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1112)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:993)
> 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:138)
> 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:483)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
> {noformat}
> After hitting Finish on wizard, the imported project (if it was imported) cannot be build, because it cannot resolve maven-resources-plugin. Error log:
> {noformat:title=Errors occurred during the build.}
> org.eclipse.core.internal.resources.ResourceException: Errors occurred during the build.
> at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:498)
> at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:398)
> at org.jboss.tools.project.examples.internal.ProjectExamplesActivator$1.run(ProjectExamplesActivator.java:207)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Contains: Errors running builder 'Maven Project Builder' on project 'jboss-greeter'.
> org.eclipse.core.runtime.CoreException: Could not calculate build plan: Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:2.6
> at org.eclipse.m2e.core.internal.embedder.MavenImpl.setupMojoExecution(MavenImpl.java:410)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl$2.call(MavenImpl.java:420)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl$2.call(MavenImpl.java:1)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl.setupMojoExecution(MavenImpl.java:418)
> at org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.setupMojoExecution(ProjectRegistryManager.java:950)
> at org.eclipse.m2e.core.internal.project.registry.MavenProjectFacade.getMojoExecution(MavenProjectFacade.java:408)
> at org.eclipse.m2e.core.project.configurator.AbstractCustomizableLifecycleMapping.getBuildParticipants(AbstractCustomizableLifecycleMapping.java:66)
> at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1$1.call(MavenBuilder.java:113)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)
> at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1.call(MavenBuilder.java:105)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99)
> at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86)
> at org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:200)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:205)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:245)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:300)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:359)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:382)
> at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:486)
> at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:398)
> at org.jboss.tools.project.examples.internal.ProjectExamplesActivator$1.run(ProjectExamplesActivator.java:207)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:2.6
> at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:117)
> at org.eclipse.m2e.core.internal.project.registry.EclipsePluginDependenciesResolver.resolve(EclipsePluginDependenciesResolver.java:47)
> at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:179)
> at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:298)
> at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:241)
> at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.setupMojoExecution(DefaultLifecycleExecutionPlanCalculator.java:169)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl.setupMojoExecution(MavenImpl.java:408)
> ... 30 more
> Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:2.6
> at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:302)
> at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:218)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:287)
> at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:103)
> ... 36 more
> Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Failure to transfer org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced. Original error: Could not transfer artifact org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from/to central (https://repo.maven.apache.org/maven2): repo.maven.apache.org
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:444)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
> at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:287)
> ... 39 more
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Failure to transfer org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced. Original error: Could not transfer artifact org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from/to central (https://repo.maven.apache.org/maven2): repo.maven.apache.org
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.newException(DefaultUpdateCheckManager.java:238)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkArtifact(DefaultUpdateCheckManager.java:206)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.gatherDownloads(DefaultArtifactResolver.java:585)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:503)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)
> ... 42 more
> Contains: Could not calculate build plan: Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:2.6
> org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:2.6
> at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:117)
> at org.eclipse.m2e.core.internal.project.registry.EclipsePluginDependenciesResolver.resolve(EclipsePluginDependenciesResolver.java:47)
> at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:179)
> at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:298)
> at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:241)
> at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.setupMojoExecution(DefaultLifecycleExecutionPlanCalculator.java:169)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl.setupMojoExecution(MavenImpl.java:408)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl$2.call(MavenImpl.java:420)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl$2.call(MavenImpl.java:1)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)
> at org.eclipse.m2e.core.internal.embedder.MavenImpl.setupMojoExecution(MavenImpl.java:418)
> at org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.setupMojoExecution(ProjectRegistryManager.java:950)
> at org.eclipse.m2e.core.internal.project.registry.MavenProjectFacade.getMojoExecution(MavenProjectFacade.java:408)
> at org.eclipse.m2e.core.project.configurator.AbstractCustomizableLifecycleMapping.getBuildParticipants(AbstractCustomizableLifecycleMapping.java:66)
> at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1$1.call(MavenBuilder.java:113)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)
> at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1.call(MavenBuilder.java:105)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151)
> at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99)
> at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86)
> at org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:200)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:205)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:245)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:300)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:359)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:382)
> at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:486)
> at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:398)
> at org.jboss.tools.project.examples.internal.ProjectExamplesActivator$1.run(ProjectExamplesActivator.java:207)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:2.6
> at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:302)
> at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:218)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:287)
> at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:103)
> ... 36 more
> Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Failure to transfer org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced. Original error: Could not transfer artifact org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from/to central (https://repo.maven.apache.org/maven2): repo.maven.apache.org
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:444)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
> at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:287)
> ... 39 more
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Failure to transfer org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced. Original error: Could not transfer artifact org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from/to central (https://repo.maven.apache.org/maven2): repo.maven.apache.org
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.newException(DefaultUpdateCheckManager.java:238)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkArtifact(DefaultUpdateCheckManager.java:206)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.gatherDownloads(DefaultArtifactResolver.java:585)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:503)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)
> ... 42 more
> {noformat}
> Note, that all artifacts that eclipse cannot resolve (maven-resources-plugin, HTML5 archetype, ...) I have in my local repository (were downloaded by offline script correctly). I checked few sha1 checksums and they are correct.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 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:
---------------------------------------
[~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, 12 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, 12 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, 12 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, 12 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, 12 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, 12 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, 12 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 Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19719?page=com.atlassian.jira.plugi... ]
Mickael Istria reassigned JBIDE-19719:
--------------------------------------
Assignee: Gorkem Ercan (was: Max Rydahl Andersen)
> 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, 12 months
[JBoss JIRA] (TOOLSDOC-629) Publish JBT Version of HTML5 Article
by Misha Ali (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-629?page=com.atlassian.jira.plug... ]
Misha Ali commented on TOOLSDOC-629:
------------------------------------
Sent Supriya feedback on article. [~supriya.bharadwaj] please send me the folder with images so I can add this to the git repo, etc.
> Publish JBT Version of HTML5 Article
> ------------------------------------
>
> Key: TOOLSDOC-629
> URL: https://issues.jboss.org/browse/TOOLSDOC-629
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Sub-task
> Components: General documentation issues
> Reporter: Misha Ali
> Assignee: Misha Ali
>
> When Supriya has converted her article to ASCIIDoc, add this to the upstream repo, review for documentation conventions and build issues and send a PR. Implement any SME feedback and release the doc.
> Misha also needs to add the CSP version of this doc to the Splash Page.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 12 months