[JBoss JIRA] (JBIDE-14333) have context sensitive parameterized commands for open file, show type etc. with proper API
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14333?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-14333:
---------------------------------------
We can't use the \${project} syntax because the cheat sheet framework already uses the \${...} syntax. In our case a command gets "" instead of \${project}. We could use {project}.
> have context sensitive parameterized commands for open file, show type etc. with proper API
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-14333
> URL: https://issues.jboss.org/browse/JBIDE-14333
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: project-examples
> Reporter: Max Rydahl Andersen
> Fix For: 4.1.0.Beta1, 4.1.0.Beta2
>
>
> currently our custom cheatsheet commands requires the project name(s) to be known upfront. We should make them less reliant on project names and if at all possible have the project name calculated based on the project the cheatsheet file is open in.
> The commands should also actually be commands with named parameters so the order of parameters does not matter and we should make sure these have a good and long term API so cheatsheets will continue to work well in the future.
--
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
13 years, 1 month
[JBoss JIRA] (JBIDE-14333) have context sensitive parameterized commands for open file, show type etc. with proper API
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14333?page=com.atlassian.jira.plugi... ]
Snjezana Peco edited comment on JBIDE-14333 at 5/14/13 6:02 PM:
----------------------------------------------------------------
We can't use the $\{project\} syntax because the cheat sheet framework already uses the $\{...\} syntax. In our case a command gets "" instead of $\{project\}. We could use \{project\}.
was (Author: snjeza):
We can't use the \${project} syntax because the cheat sheet framework already uses the \${...} syntax. In our case a command gets "" instead of \${project}. We could use {project}.
> have context sensitive parameterized commands for open file, show type etc. with proper API
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-14333
> URL: https://issues.jboss.org/browse/JBIDE-14333
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: project-examples
> Reporter: Max Rydahl Andersen
> Fix For: 4.1.0.Beta1, 4.1.0.Beta2
>
>
> currently our custom cheatsheet commands requires the project name(s) to be known upfront. We should make them less reliant on project names and if at all possible have the project name calculated based on the project the cheatsheet file is open in.
> The commands should also actually be commands with named parameters so the order of parameters does not matter and we should make sure these have a good and long term API so cheatsheets will continue to work well in the future.
--
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
13 years, 1 month
[JBoss JIRA] (JBIDE-14450) Code completion for IDs in <a href="#..."> should use IDs of pages, dialogs, popup only
by Alexey Kazakov (JIRA)
Alexey Kazakov created JBIDE-14450:
--------------------------------------
Summary: Code completion for IDs in <a href="#..."> should use IDs of pages, dialogs, popup only
Key: JBIDE-14450
URL: https://issues.jboss.org/browse/JBIDE-14450
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: jsp/jsf/xml/html source editing
Reporter: Alexey Kazakov
Assignee: Alexey Kazakov
Fix For: 4.1.0.Beta1
1. Create a jQuery Mobile HTML5 file.
2. Open it with VPE.
3. Add a few pages there with IDs.
4. Add <a id="testId" href="">Test</a>
5. Ctrl+Space in href="|"
6. There is testId among all the IDs. This is not ok. We should show only IDs of pages, dialogs and popups there.
--
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
13 years, 1 month
[JBoss JIRA] (JBIDE-14448) Build doesn't detect cycle dependencies between JBossTools modules
by Denis Golovin (JIRA)
Denis Golovin created JBIDE-14448:
-------------------------------------
Summary: Build doesn't detect cycle dependencies between JBossTools modules
Key: JBIDE-14448
URL: https://issues.jboss.org/browse/JBIDE-14448
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: Build/Releng
Affects Versions: 4.1.0.Beta1
Reporter: Denis Golovin
Assignee: Nick Boldt
Currently every component references nightly composite update site during the build to get dependencies. That leads to possibility to introduce cycle dependencies between components that is not detected by build.
Here is example of PR introduced a cycle between JST and VPE. Build works because JST have access to VPE BrowserSim through nightly composite update site.
The solution would be to reference specific nightly update sites for modules that are dependencies for current one.
In this case JST should have reference only to base composite nightly update site. That would solve cycle dependency detection problem and speed up the build because it would not require to download and analyse all metadata from jbosstools nightly composite update site.
--
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
13 years, 1 month
[JBoss JIRA] (JBIDE-14396) Imported maven projects sometimes fail to resolve required classpath dependencies for tests
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14396?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-14396:
-------------------------------------
I totally agree with you about what the default behavior should be in m2e. But Igor doesn't and he's the project lead of m2e.
> Imported maven projects sometimes fail to resolve required classpath dependencies for tests
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-14396
> URL: https://issues.jboss.org/browse/JBIDE-14396
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven, upstream
> Affects Versions: 4.1.0.Alpha2
> Reporter: Lincoln Baxter III
> Attachments: m2e-forge.site-0.0.1-SNAPSHOT.zip
>
>
> Example project: https://github.com/forge/core/tree/M2ECLIPSE-BUG
> Steps to reproduce:
> * Import all modules into the workspace.
> * Select "aesh-tests" project.
> * Run as -> JUnit Test
> You should see the test fail to launch because of the following Class not found exception:
> {code}
> java.lang.NoClassDefFoundError: Lorg/jboss/forge/aesh/TestShellConfiguration;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2300)
> at java.lang.Class.getDeclaredFields(Class.java:1745)
> at org.junit.runners.model.TestClass.<init>(TestClass.java:49)
> at org.junit.runners.ParentRunner.<init>(ParentRunner.java:75)
> at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:57)
> at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29)
> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: java.lang.ClassNotFoundException: org.jboss.forge.aesh.TestShellConfiguration
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> ... 25 more
> {code}
> This can be solved by manually adding required projects in the workspace as classpath dependencies of the JUnit launch configured for the project being tested, but this is obviously not right, and should be configured automatically by the M2E integration.
--
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
13 years, 1 month
[JBoss JIRA] (JBIDE-14396) Imported maven projects sometimes fail to resolve required classpath dependencies for tests
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14396?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-14396:
-------------------------------------
For the moment, the m2e-forge plugin I hacked has no official support anywhere. That was a quick'n dirty workaround for your issue.
We *may* be able to have m2e discover such a plugin if, for instance, it was mapped to the forge-maven-plugin AND some forge-maven-plugin goal was participating to an [interesting maven execution phase|https://docs.sonatype.org/display/M2ECLIPSE/Project+build+lifecycle...]
> Imported maven projects sometimes fail to resolve required classpath dependencies for tests
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-14396
> URL: https://issues.jboss.org/browse/JBIDE-14396
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven, upstream
> Affects Versions: 4.1.0.Alpha2
> Reporter: Lincoln Baxter III
> Attachments: m2e-forge.site-0.0.1-SNAPSHOT.zip
>
>
> Example project: https://github.com/forge/core/tree/M2ECLIPSE-BUG
> Steps to reproduce:
> * Import all modules into the workspace.
> * Select "aesh-tests" project.
> * Run as -> JUnit Test
> You should see the test fail to launch because of the following Class not found exception:
> {code}
> java.lang.NoClassDefFoundError: Lorg/jboss/forge/aesh/TestShellConfiguration;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2300)
> at java.lang.Class.getDeclaredFields(Class.java:1745)
> at org.junit.runners.model.TestClass.<init>(TestClass.java:49)
> at org.junit.runners.ParentRunner.<init>(ParentRunner.java:75)
> at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:57)
> at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29)
> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: java.lang.ClassNotFoundException: org.jboss.forge.aesh.TestShellConfiguration
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> ... 25 more
> {code}
> This can be solved by manually adding required projects in the workspace as classpath dependencies of the JUnit launch configured for the project being tested, but this is obviously not right, and should be configured automatically by the M2E integration.
--
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
13 years, 1 month
[JBoss JIRA] (JBIDE-14396) Imported maven projects sometimes fail to resolve required classpath dependencies for tests
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14396?page=com.atlassian.jira.plugi... ]
Lincoln Baxter III commented on JBIDE-14396:
--------------------------------------------
Okay, but even in that case you are adding classes, not hiding them. Why not assume what I think is probably the most likely case, would prevent things from "pretending" to work, e.g. compile but not run, but would still be enforced when running a maven build. I dunno. I guess it does come down to preference.
Regarding the question about M2E plugin, what do you think?
> Imported maven projects sometimes fail to resolve required classpath dependencies for tests
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-14396
> URL: https://issues.jboss.org/browse/JBIDE-14396
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven, upstream
> Affects Versions: 4.1.0.Alpha2
> Reporter: Lincoln Baxter III
> Attachments: m2e-forge.site-0.0.1-SNAPSHOT.zip
>
>
> Example project: https://github.com/forge/core/tree/M2ECLIPSE-BUG
> Steps to reproduce:
> * Import all modules into the workspace.
> * Select "aesh-tests" project.
> * Run as -> JUnit Test
> You should see the test fail to launch because of the following Class not found exception:
> {code}
> java.lang.NoClassDefFoundError: Lorg/jboss/forge/aesh/TestShellConfiguration;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2300)
> at java.lang.Class.getDeclaredFields(Class.java:1745)
> at org.junit.runners.model.TestClass.<init>(TestClass.java:49)
> at org.junit.runners.ParentRunner.<init>(ParentRunner.java:75)
> at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:57)
> at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29)
> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: java.lang.ClassNotFoundException: org.jboss.forge.aesh.TestShellConfiguration
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> ... 25 more
> {code}
> This can be solved by manually adding required projects in the workspace as classpath dependencies of the JUnit launch configured for the project being tested, but this is obviously not right, and should be configured automatically by the M2E integration.
--
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
13 years, 1 month
[JBoss JIRA] (JBIDE-14396) Imported maven projects sometimes fail to resolve required classpath dependencies for tests
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14396?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-14396:
-------------------------------------
{quote}wouldn't the dependencies be the same?{quote}
In theory no, since the exposed classes would be different. In practice they would, since we don't have that level of granularity in eclipse.
ejb-client was probably not the best example. Take the "tests" classifier for instance. It basically exposes tests classes to the runtime classpath (not only the test classpath)
> Imported maven projects sometimes fail to resolve required classpath dependencies for tests
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-14396
> URL: https://issues.jboss.org/browse/JBIDE-14396
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven, upstream
> Affects Versions: 4.1.0.Alpha2
> Reporter: Lincoln Baxter III
> Attachments: m2e-forge.site-0.0.1-SNAPSHOT.zip
>
>
> Example project: https://github.com/forge/core/tree/M2ECLIPSE-BUG
> Steps to reproduce:
> * Import all modules into the workspace.
> * Select "aesh-tests" project.
> * Run as -> JUnit Test
> You should see the test fail to launch because of the following Class not found exception:
> {code}
> java.lang.NoClassDefFoundError: Lorg/jboss/forge/aesh/TestShellConfiguration;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2300)
> at java.lang.Class.getDeclaredFields(Class.java:1745)
> at org.junit.runners.model.TestClass.<init>(TestClass.java:49)
> at org.junit.runners.ParentRunner.<init>(ParentRunner.java:75)
> at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:57)
> at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29)
> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: java.lang.ClassNotFoundException: org.jboss.forge.aesh.TestShellConfiguration
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> ... 25 more
> {code}
> This can be solved by manually adding required projects in the workspace as classpath dependencies of the JUnit launch configured for the project being tested, but this is obviously not right, and should be configured automatically by the M2E integration.
--
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
13 years, 1 month