[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
6 days, 12 hours
[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
[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
1 month
[JBoss JIRA] (JBIDE-26311) EAP 7.1 fails to stop when connected over ssh
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26311?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-26311:
-------------------------------------
I'm not able to replicate. I've attached a screencast. I will admit this screencast was using a "localhost" type connection instead of ssh, but, once I realized that, I re-ran my test with an ssh connection and noticed no difference.
I mean... i COULD make a new video with teh correct connection type, but, I promise you it appears to work fine.
Caveats: I'm using the new TP, AM3 version, which Nick pushed out last night. Seems to work :|
> EAP 7.1 fails to stop when connected over ssh
> ---------------------------------------------
>
> Key: JBIDE-26311
> URL: https://issues.jboss.org/browse/JBIDE-26311
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.9.0.AM2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Labels: regression
> Attachments: JBIDE-26311.local.ogv
>
>
> I have an EAP 7.1 setup up over ssh. It's running on my localhost, so it's the most basic test of an ssh server. When I click the stop button on the server, it says:
> Server Red Hat JBoss EAP 7.1 ssh failed to stop.
> An exception stack trace is not available.
> It will stop on second attempt. On a local server this would mean killing the server java process. I'm not sure exactly what happens on a remote server, but it works.
> I'm pretty sure this worked last time (previous milestone).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 4 months
[JBoss JIRA] (JBIDE-26311) EAP 7.1 fails to stop when connected over ssh
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26311?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-26311:
--------------------------------
Attachment: JBIDE-26311.local.ogv
> EAP 7.1 fails to stop when connected over ssh
> ---------------------------------------------
>
> Key: JBIDE-26311
> URL: https://issues.jboss.org/browse/JBIDE-26311
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.9.0.AM2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Labels: regression
> Attachments: JBIDE-26311.local.ogv
>
>
> I have an EAP 7.1 setup up over ssh. It's running on my localhost, so it's the most basic test of an ssh server. When I click the stop button on the server, it says:
> Server Red Hat JBoss EAP 7.1 ssh failed to stop.
> An exception stack trace is not available.
> It will stop on second attempt. On a local server this would mean killing the server java process. I'm not sure exactly what happens on a remote server, but it works.
> I'm pretty sure this worked last time (previous milestone).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 4 months
[JBoss JIRA] (JBDS-4711) Add support for LFS via egit to Devstudio/JBoss Tools? (was ClassNotFoundException in Error Log after start: Builtin LFS support not present/detected)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4711?page=com.atlassian.jira.plugin.... ]
Nick Boldt reassigned JBDS-4711:
--------------------------------
Assignee: Josef Kopriva (was: Nick Boldt)
> Add support for LFS via egit to Devstudio/JBoss Tools? (was ClassNotFoundException in Error Log after start: Builtin LFS support not present/detected)
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-4711
> URL: https://issues.jboss.org/browse/JBDS-4711
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build, upstream
> Affects Versions: 12.0.0.GA
> Environment: F28 + 12.0.0.GA-v20180625-0632-B2859
> Reporter: Josef Kopriva
> Assignee: Josef Kopriva
> Priority: Minor
> Fix For: 12.9.0.AM3
>
>
> After every start of devstudio, there is a warning:
> {code:java}
> eclipse.buildId=12.0.0.GA-v20180625-0632-B2859
> java.version=1.8.0_172
> java.vendor=Oracle Corporation
> BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
> Framework arguments: -product com.jboss.devstudio.core.product
> Command-line arguments: -data file:/home/jkopriva/devstudio_B2859_2/workspace/ -os linux -ws gtk -arch x86_64 -product com.jboss.devstudio.core.product
> org.eclipse.egit.core
> Warning
> Mon Jun 25 13:18:32 CEST 2018
> Builtin LFS support not present/detected
> java.lang.ClassNotFoundException: org.eclipse.jgit.lfs.BuiltinLFS cannot be found by org.eclipse.egit.core_5.0.0.201806131550-r
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.eclipse.egit.core.Activator.registerBuiltinLFS(Activator.java:279)
> at org.eclipse.egit.core.Activator.start(Activator.java:212)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:779)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:772)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:729)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1002)
> at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:354)
> at org.eclipse.osgi.container.Module.doStart(Module.java:581)
> at org.eclipse.osgi.container.Module.start(Module.java:449)
> at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468)
> at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:114)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:505)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:328)
> at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:392)
> at org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:36)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:454)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at org.eclipse.egit.ui.Activator$RepositoryChangeScanner.<init>(Activator.java:921)
> at org.eclipse.egit.ui.Activator.setupRepoChangeScanner(Activator.java:1034)
> at org.eclipse.egit.ui.Activator.start(Activator.java:336)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:779)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:772)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:729)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1002)
> at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:354)
> at org.eclipse.osgi.container.Module.doStart(Module.java:581)
> at org.eclipse.osgi.container.Module.start(Module.java:449)
> at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468)
> at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:114)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:505)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:328)
> at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:392)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:470)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.loadClass(EquinoxBundle.java:609)
> at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:177)
> at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:931)
> at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
> at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:60)
> at org.eclipse.ui.internal.services.WorkbenchServiceRegistry.getSourceProviders(WorkbenchServiceRegistry.java:174)
> at org.eclipse.ui.internal.services.SourceProviderService.readRegistry(SourceProviderService.java:104)
> at org.eclipse.ui.internal.Workbench$34.runWithException(Workbench.java:2378)
> at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:32)
> at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:233)
> at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:144)
> at org.eclipse.swt.widgets.Display.syncExec(Display.java:5831)
> at org.eclipse.ui.internal.StartupThreading.runWithoutExceptions(StartupThreading.java:95)
> at org.eclipse.ui.internal.Workbench.initializeDefaultServices(Workbench.java:2373)
> at org.eclipse.ui.internal.Workbench.init(Workbench.java:1654)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2859)
> at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:654)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:597)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152)
> 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:388)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
> 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:498)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:656)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:592)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1498)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1471)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 4 months
[JBoss JIRA] (JBDS-4711) Add support for LFS via egit to Devstudio/JBoss Tools? (was ClassNotFoundException in Error Log after start: Builtin LFS support not present/detected)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4711?page=com.atlassian.jira.plugin.... ]
Nick Boldt resolved JBDS-4711.
------------------------------
Resolution: Done
We're now using egit/jgit 5.1 [1] so I assume this is fixed. I'll let [~jkopriva] verify and close or reopen if it's still a problem.
[1] http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.9...
> Add support for LFS via egit to Devstudio/JBoss Tools? (was ClassNotFoundException in Error Log after start: Builtin LFS support not present/detected)
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-4711
> URL: https://issues.jboss.org/browse/JBDS-4711
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build, upstream
> Affects Versions: 12.0.0.GA
> Environment: F28 + 12.0.0.GA-v20180625-0632-B2859
> Reporter: Josef Kopriva
> Assignee: Nick Boldt
> Priority: Minor
> Fix For: 12.9.0.AM3
>
>
> After every start of devstudio, there is a warning:
> {code:java}
> eclipse.buildId=12.0.0.GA-v20180625-0632-B2859
> java.version=1.8.0_172
> java.vendor=Oracle Corporation
> BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
> Framework arguments: -product com.jboss.devstudio.core.product
> Command-line arguments: -data file:/home/jkopriva/devstudio_B2859_2/workspace/ -os linux -ws gtk -arch x86_64 -product com.jboss.devstudio.core.product
> org.eclipse.egit.core
> Warning
> Mon Jun 25 13:18:32 CEST 2018
> Builtin LFS support not present/detected
> java.lang.ClassNotFoundException: org.eclipse.jgit.lfs.BuiltinLFS cannot be found by org.eclipse.egit.core_5.0.0.201806131550-r
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.eclipse.egit.core.Activator.registerBuiltinLFS(Activator.java:279)
> at org.eclipse.egit.core.Activator.start(Activator.java:212)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:779)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:772)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:729)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1002)
> at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:354)
> at org.eclipse.osgi.container.Module.doStart(Module.java:581)
> at org.eclipse.osgi.container.Module.start(Module.java:449)
> at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468)
> at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:114)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:505)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:328)
> at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:392)
> at org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:36)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:454)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at org.eclipse.egit.ui.Activator$RepositoryChangeScanner.<init>(Activator.java:921)
> at org.eclipse.egit.ui.Activator.setupRepoChangeScanner(Activator.java:1034)
> at org.eclipse.egit.ui.Activator.start(Activator.java:336)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:779)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:772)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:729)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1002)
> at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:354)
> at org.eclipse.osgi.container.Module.doStart(Module.java:581)
> at org.eclipse.osgi.container.Module.start(Module.java:449)
> at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468)
> at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:114)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:505)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:328)
> at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:392)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:470)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.loadClass(EquinoxBundle.java:609)
> at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:177)
> at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:931)
> at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
> at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:60)
> at org.eclipse.ui.internal.services.WorkbenchServiceRegistry.getSourceProviders(WorkbenchServiceRegistry.java:174)
> at org.eclipse.ui.internal.services.SourceProviderService.readRegistry(SourceProviderService.java:104)
> at org.eclipse.ui.internal.Workbench$34.runWithException(Workbench.java:2378)
> at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:32)
> at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:233)
> at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:144)
> at org.eclipse.swt.widgets.Display.syncExec(Display.java:5831)
> at org.eclipse.ui.internal.StartupThreading.runWithoutExceptions(StartupThreading.java:95)
> at org.eclipse.ui.internal.Workbench.initializeDefaultServices(Workbench.java:2373)
> at org.eclipse.ui.internal.Workbench.init(Workbench.java:1654)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2859)
> at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:654)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:597)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152)
> 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:388)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
> 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:498)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:656)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:592)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1498)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1471)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 4 months