[JBoss JIRA] (JBDS-4133) org.jboss.tools.ws.jaxrs.core :: error occurred during JAX-RS Metamodel build - java.lang.NoClassDefFoundError: org/apache/lucene/analysis/standard/StandardAnalyzer
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4133?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-4133:
-----------------------------
Attachment: TEST-org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite.xml
org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite.txt
> org.jboss.tools.ws.jaxrs.core :: error occurred during JAX-RS Metamodel build - java.lang.NoClassDefFoundError: org/apache/lucene/analysis/standard/StandardAnalyzer
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-4133
> URL: https://issues.jboss.org/browse/JBDS-4133
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build, rpm, target-platform, webservices
> Affects Versions: 10.2.0.AM2
> Reporter: Nick Boldt
> Assignee: Xavier Coulon
> Priority: Blocker
> Fix For: 10.2.0.GA
>
> Attachments: image-2016-11-08-19-07-53-492.png, lucene3.5corevs.5.4.1analyzers-common.png, lucene3.5corevs.5.4.1queryparser.png, org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite.txt, org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite.txt, osgi-console-lucene.png, TEST-org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite.xml, TEST-org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite.xml
>
>
> I'm getting this problem after running the HTML5 quickstart. I've installed this [1] version of the rpm.
> {code}
> !ENTRY org.eclipse.core.jobs 4 2 2016-10-26 16:22:07.578
> !MESSAGE An internal error occurred during: "JAX-RS Metamodel build...".
> !STACK 0
> java.lang.NoClassDefFoundError: org/apache/lucene/analysis/standard/StandardAnalyzer
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsMetamodel.<init>(JaxrsMetamodel.java:163)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsMetamodel.create(JaxrsMetamodel.java:278)
> at org.jboss.tools.ws.jaxrs.core.metamodel.domain.JaxrsMetamodelLocator.get(JaxrsMetamodelLocator.java:120)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.ResourceChangedBuildJob.run(ResourceChangedBuildJob.java:68)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.ClassNotFoundException: org.apache.lucene.analysis.standard.StandardAnalyzer cannot be found by org.jboss.tools.ws.jaxrs.core_1.9.2.v20161011-1002
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 5 more
> {code}
> [1] https://devstudio.jboss.com/10.0/snapshots/builds/devstudio.rpm_master/20...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBDS-4133) org.jboss.tools.ws.jaxrs.core :: error occurred during JAX-RS Metamodel build - java.lang.NoClassDefFoundError: org/apache/lucene/analysis/standard/StandardAnalyzer
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4133?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-4133:
----------------------------------
Ran this PR ( https://github.com/jbosstools/jbosstools-webservices/pull/257 ) locally after the switch to the AM3 TP with Lucene 5.4.1 and 3.5.0, and only one test suite failed:
[INFO] org.jboss.tools.ws.creation.core.test .............. FAILURE [05:19 min]
[^TEST-org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite.xml]
[^org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite.txt]
> org.jboss.tools.ws.jaxrs.core :: error occurred during JAX-RS Metamodel build - java.lang.NoClassDefFoundError: org/apache/lucene/analysis/standard/StandardAnalyzer
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-4133
> URL: https://issues.jboss.org/browse/JBDS-4133
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build, rpm, target-platform, webservices
> Affects Versions: 10.2.0.AM2
> Reporter: Nick Boldt
> Assignee: Xavier Coulon
> Priority: Blocker
> Fix For: 10.2.0.GA
>
> Attachments: image-2016-11-08-19-07-53-492.png, lucene3.5corevs.5.4.1analyzers-common.png, lucene3.5corevs.5.4.1queryparser.png, org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite.txt, org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite.txt, osgi-console-lucene.png, TEST-org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite.xml, TEST-org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite.xml
>
>
> I'm getting this problem after running the HTML5 quickstart. I've installed this [1] version of the rpm.
> {code}
> !ENTRY org.eclipse.core.jobs 4 2 2016-10-26 16:22:07.578
> !MESSAGE An internal error occurred during: "JAX-RS Metamodel build...".
> !STACK 0
> java.lang.NoClassDefFoundError: org/apache/lucene/analysis/standard/StandardAnalyzer
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsMetamodel.<init>(JaxrsMetamodel.java:163)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsMetamodel.create(JaxrsMetamodel.java:278)
> at org.jboss.tools.ws.jaxrs.core.metamodel.domain.JaxrsMetamodelLocator.get(JaxrsMetamodelLocator.java:120)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.ResourceChangedBuildJob.run(ResourceChangedBuildJob.java:68)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.ClassNotFoundException: org.apache.lucene.analysis.standard.StandardAnalyzer cannot be found by org.jboss.tools.ws.jaxrs.core_1.9.2.v20161011-1002
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 5 more
> {code}
> [1] https://devstudio.jboss.com/10.0/snapshots/builds/devstudio.rpm_master/20...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-23321) Integration tests for OpenShift Node.js debugger
by Pavol Srna (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23321?page=com.atlassian.jira.plugi... ]
Pavol Srna commented on JBIDE-23321:
------------------------------------
[~adietish] yes, I plan to have an automatic install of minishift. Because it runs on rhel in central-ci, and it's pretty simple to run. E.g. only yum install libvirt kvm, usermod -a -G libvirt hudson, and then only wget the binary and run. So I basically got openshift instance running very easily. Disadvatange is that there are no templates on minishift.
I'll try the CDK path too. It just seemed to me (as I'm not the openshift/cdk expert) that minishift is easier to run. And btw. I think cdk guys are investigating minishift for possible use in cdk 3.0.
But I think we both agree that we need to have the tests running in central-ci.
> Integration tests for OpenShift Node.js debugger
> -------------------------------------------------
>
> Key: JBIDE-23321
> URL: https://issues.jboss.org/browse/JBIDE-23321
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: javascript, openshift
> Affects Versions: 4.4.2.AM1
> Reporter: Ilya Buziuk
> Assignee: Pavol Srna
> Fix For: 4.4.2.Final
>
>
> Node.js Debugging support implemented as part of https://issues.jboss.org/browse/JBIDE-22225
> Should be covered with red deer integration tests. Basically, test coverage of Node.js Debugger facilities already covered with red deer in JSDT project - https://git.eclipse.org/r/#/c/82836/
> However, implementing smth. similar for OpenShift will be much trickier. Basically, there is an integration test *org.jboss.tools.openshift.ui.bot.test.application.v3.adapter.PublishChangesTest* which is used for server adapter publishing. For now this test is not sustainable due to https://issues.jboss.org/browse/JBIDE-23005 .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-23481) build target platform sources site (for use with TP and PDE Source Lookup)
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23481?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-23481:
----------------------------------------
For PDE, there's
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=282352
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=507397
Fixing those 2 issue would be a definitive improvement to usability of Target Platforms.
> build target platform sources site (for use with TP and PDE Source Lookup)
> --------------------------------------------------------------------------
>
> Key: JBIDE-23481
> URL: https://issues.jboss.org/browse/JBIDE-23481
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, target-platform
> Affects Versions: 4.4.2.AM3
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.x
>
>
> So that dev and qe can use Fred's PDE source lookup tool [1] to grab source bundles on demand (instead of having to build a target platform locally w/ all the sources [2]), we need to:
> [1] https://github.com/fbricon/pde.source.lookup/
> [2] https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/targ...
> * build a targetplatform with all the sources
> * split that repo into two pieces: all the .source files, and everything else
> * regen the metadata (featureandbundlepublisher) in each new repo so that all the features/plugins are uncategorized
> OR...
> * build a targetplatform without the sources
> * transform the .target file so that each IU ends with .source
> * build the target platform repo from the new .target file
> * verify that sources repo includes the sources of nested features, and those features' plugins' sources too
> ----
> Then once we have the targetplatform.source repo, publish that and verify it works with the PDE Source Lookup plugin:
> 1. install the PDE source lookup plugin
> 2. Window > Prefs > Update > Avail Software Sites > Add the new tp.source site
> 3. for something you want sources, use the plugin and see if it can resolve soources
> ----
> Then, if that works, we can consider adding the new tp.source site into the JBT/devstudio composite sites, along with jbt + tp + central + central tp (or ds + ds tp + central + central tp) as a 5th child site.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-23481) build target platform sources site (for use with TP and PDE Source Lookup)
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23481?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-23481:
----------------------------------------
Note that adding source to TP site by default would also benefit to regular TP usage.
{quote}The target file in eclipse suffers from a lot of drawbacks. Depending on your country, it can be very slow to resolve (up to 1 hour for normal people, up to 2 or 3 hours for me in China). There was no real ability to 'retry' or 'continue', as I could when building TP locally. And, when creating a new workspace, I found it to be completely impossible to find where the TP data was cached in the old workspace to quickly have the new workspace make use of it. {quote}
Are there bugs et eclipse.org on this issue? I have some ideas of how to improve that state, without too much hard work and directly into PDE. Namely:
1. Make all TP fetch content in the same directory/bundle_pool to avoid unnecessary re-fetch if some TPs share content. A TP resolution happens to be a subset of this bundle-pool.
2. Make the TP resolution able to also consume the current installation bundle_pool so it would reuse local artifacts if you have them installed instead of fetching them
3. Make Target-Platform resolution able to resolve sources directly against current installation in case the TP doesn't contain them
4. Maybe even make the default bundle pool in a user-specific directory rather than workspace, so it can be shared between instances. BTW, it's what Oomph is using.
If you're interested, please open bugs for each of this proposal, and consider contributing such changes to PDE. PDE welcome now welcome changes.
[~rob.stryker] For your workflow, all you want is a TP site to contain sources by default, and to download the zip to create your TP locally.
Fixing the 4 issues mentionted above would be a major improvement for PDE, and would prevent people from having to implement new plugins that basically try to re-implement the TP paradigm in different ways, just to troubleshoot some issue.
> build target platform sources site (for use with TP and PDE Source Lookup)
> --------------------------------------------------------------------------
>
> Key: JBIDE-23481
> URL: https://issues.jboss.org/browse/JBIDE-23481
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, target-platform
> Affects Versions: 4.4.2.AM3
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.x
>
>
> So that dev and qe can use Fred's PDE source lookup tool [1] to grab source bundles on demand (instead of having to build a target platform locally w/ all the sources [2]), we need to:
> [1] https://github.com/fbricon/pde.source.lookup/
> [2] https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/targ...
> * build a targetplatform with all the sources
> * split that repo into two pieces: all the .source files, and everything else
> * regen the metadata (featureandbundlepublisher) in each new repo so that all the features/plugins are uncategorized
> OR...
> * build a targetplatform without the sources
> * transform the .target file so that each IU ends with .source
> * build the target platform repo from the new .target file
> * verify that sources repo includes the sources of nested features, and those features' plugins' sources too
> ----
> Then once we have the targetplatform.source repo, publish that and verify it works with the PDE Source Lookup plugin:
> 1. install the PDE source lookup plugin
> 2. Window > Prefs > Update > Avail Software Sites > Add the new tp.source site
> 3. for something you want sources, use the plugin and see if it can resolve soources
> ----
> Then, if that works, we can consider adding the new tp.source site into the JBT/devstudio composite sites, along with jbt + tp + central + central tp (or ds + ds tp + central + central tp) as a 5th child site.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-23479) Seam doesn't compile because of changes in Hibernate
by Koen Aers (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23479?page=com.atlassian.jira.plugi... ]
Koen Aers commented on JBIDE-23479:
-----------------------------------
I'll take care of it.
> Seam doesn't compile because of changes in Hibernate
> ----------------------------------------------------
>
> Key: JBIDE-23479
> URL: https://issues.jboss.org/browse/JBIDE-23479
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate, seam2
> Affects Versions: 4.4.2.AM3
> Reporter: Alexey Kazakov
> Assignee: Koen Aers
> Priority: Blocker
> Fix For: 4.4.2.Final
>
>
> {code}
> [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:0.26.0:compile (default-compile) on project org.jboss.tools.seam.ui: Compilation failure: Compilation failure:
> [ERROR] /home/igels/Projects/jbt-4.0/contribution-neon/jbosstools-javaee/seam/plugins/org.jboss.tools.seam.ui/src/org/jboss/tools/seam/ui/views/DBTablesViewer.java:[158]
> [ERROR] List schemaNames = tablesCollector.getMatchingSchemaNames(catalog.getName(), buildSettings.getDefaultSchemaName());
> [ERROR] ^^^^^^^^^^^^^^^^^^^^
> [ERROR] The method getDefaultSchemaName() is undefined for the type ISettings
> [ERROR] /home/igels/Projects/jbt-4.0/contribution-neon/jbosstools-javaee/seam/plugins/org.jboss.tools.seam.ui/src/org/jboss/tools/seam/ui/views/DBTablesViewer.java:[221]
> [ERROR] reader.readDatabaseTables(tablesCollector, buildSettings.getDefaultCatalogName(), buildSettings.getDefaultSchemaName());
> [ERROR] ^^^^^^^^^^^^^^^^^^^^^
> [ERROR] The method getDefaultCatalogName() is undefined for the type ISettings
> [ERROR] /home/igels/Projects/jbt-4.0/contribution-neon/jbosstools-javaee/seam/plugins/org.jboss.tools.seam.ui/src/org/jboss/tools/seam/ui/views/DBTablesViewer.java:[221]
> [ERROR] reader.readDatabaseTables(tablesCollector, buildSettings.getDefaultCatalogName(), buildSettings.getDefaultSchemaName());
> [ERROR] ^^^^^^^^^^^^^^^^^^^^
> [ERROR] The method getDefaultSchemaName() is undefined for the type ISettings
> [ERROR] 3 problems (3 errors)
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the command
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-23481) build target platform sources site (for use with TP and PDE Source Lookup)
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23481?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-23481:
-----------------------------------
Summary: build target platform sources site (for use with TP and PDE Source Lookup) (was: build target platform sources site (for use with PDE Source Lookup))
> build target platform sources site (for use with TP and PDE Source Lookup)
> --------------------------------------------------------------------------
>
> Key: JBIDE-23481
> URL: https://issues.jboss.org/browse/JBIDE-23481
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, target-platform
> Affects Versions: 4.4.2.AM3
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.x
>
>
> So that dev and qe can use Fred's PDE source lookup tool [1] to grab source bundles on demand (instead of having to build a target platform locally w/ all the sources [2]), we need to:
> [1] https://github.com/fbricon/pde.source.lookup/
> [2] https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/targ...
> * build a targetplatform with all the sources
> * split that repo into two pieces: all the .source files, and everything else
> * regen the metadata (featureandbundlepublisher) in each new repo so that all the features/plugins are uncategorized
> OR...
> * build a targetplatform without the sources
> * transform the .target file so that each IU ends with .source
> * build the target platform repo from the new .target file
> * verify that sources repo includes the sources of nested features, and those features' plugins' sources too
> ----
> Then once we have the targetplatform.source repo, publish that and verify it works with the PDE Source Lookup plugin:
> 1. install the PDE source lookup plugin
> 2. Window > Prefs > Update > Avail Software Sites > Add the new tp.source site
> 3. for something you want sources, use the plugin and see if it can resolve soources
> ----
> Then, if that works, we can consider adding the new tp.source site into the JBT/devstudio composite sites, along with jbt + tp + central + central tp (or ds + ds tp + central + central tp) as a 5th child site.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-23481) build target platform sources site (for use with PDE Source Lookup)
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23481?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-23481:
-------------------------------------
I've used Fred's lookup plugin once in the past, when I was evaluating / testing for him whether it worked at all. I haven't used it in a long time since, unfortunately. My impressions at the time are hard to recall exactly, but I'll try.
In general, I liked that it would fetch sources if you didn't have them, but I always already had them, for a few reasons. The reason is I don't use a .target file directly.
The target file in eclipse suffers from a lot of drawbacks. Depending on your country, it can be very slow to resolve (up to 1 hour for normal people, up to 2 or 3 hours for me in China). There was no real ability to 'retry' or 'continue', as I could when building TP locally. And, when creating a new workspace, I found it to be completely impossible to find where the TP data was cached in the old workspace to quickly have the new workspace make use of it.
What's worse, I often needed different TPs. I often need the JBT one, or, an older maintenance one different than master, or the JBTIS TP, etc. Trying to switch workspaces between these environments could sap 2 or 3 hours of my day *on a good day*, or make me 100% useless on a bad one.
Basically, I evaluated Fred's plugin as it fit into my current workflow, and Fred's plugin, while nice, didn't fit into my workflow.
However, it seems there are new workflows that could exist that would be very easy and for which Fred's plugin could be very handy. For example, a dev could download the TP zip file (instead of building locally with sources flag), and then install the sources plugin.
Unfortunately, I'd need to evaluate this workflow, as I haven't evaluated it in the past. And since my current workflow of building TP on my own with sources works so well, I'm not really sure it's worth my effort to completely change my format.
However, since a new TP is being released as we speak, I may feel generous enough to test a new workflow with it and get back to you with more details.
> build target platform sources site (for use with PDE Source Lookup)
> -------------------------------------------------------------------
>
> Key: JBIDE-23481
> URL: https://issues.jboss.org/browse/JBIDE-23481
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, target-platform
> Affects Versions: 4.4.2.AM3
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.x
>
>
> So that dev and qe can use Fred's PDE source lookup tool [1] to grab source bundles on demand (instead of having to build a target platform locally w/ all the sources [2]), we need to:
> [1] https://github.com/fbricon/pde.source.lookup/
> [2] https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/targ...
> * build a targetplatform with all the sources
> * split that repo into two pieces: all the .source files, and everything else
> * regen the metadata (featureandbundlepublisher) in each new repo so that all the features/plugins are uncategorized
> OR...
> * build a targetplatform without the sources
> * transform the .target file so that each IU ends with .source
> * build the target platform repo from the new .target file
> * verify that sources repo includes the sources of nested features, and those features' plugins' sources too
> ----
> Then once we have the targetplatform.source repo, publish that and verify it works with the PDE Source Lookup plugin:
> 1. install the PDE source lookup plugin
> 2. Window > Prefs > Update > Avail Software Sites > Add the new tp.source site
> 3. for something you want sources, use the plugin and see if it can resolve soources
> ----
> Then, if that works, we can consider adding the new tp.source site into the JBT/devstudio composite sites, along with jbt + tp + central + central tp (or ds + ds tp + central + central tp) as a 5th child site.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-23321) Integration tests for OpenShift Node.js debugger
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23321?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-23321 at 11/11/16 6:04 AM:
--------------------------------------------------------------------
[~psrna] You plan on trying to have an automatic install of minishift?
A few argument to counterbalance:
* Isnt that somehow duplicating our efforts for a CDK installer?
* aren't we adding one more dependecy that we then have to maintain, while in CDK, we have to anyhow and have people that help?
I'm not saying that we shouldnt go minishift. I dont know minishift enough. Looking at the minishift description I feel like it isnt that much simpler: It's mostly just the vagrant part that's missing. The other depenencies are there too: KVM/Virtualbox etc. And then you have to duplicate the template install script that we have in CDK (via oc).
[~hardy.ferentschik] dare to comment?
was (Author: adietish):
[~psrna] You plan on trying to have an automatic install of minishift?
A few argument to counterbalance:
* Isnt that somehow duplicating our efforts for a CDK installer?
* aren't we adding one more dependecy that we then have to maintain, while in CDK, we have to anyhow and have people that help?
I'm not saying that we shouldnt go minishift. I dont know minishift enough. Looking at the minishift description I feel like it isnt that much simpler: It's mostly just the vagrant part that's missing. The other depenencies are there too: KVM/Virtualbox etc. And then you have to duplicate the template install script that we have in CDK (via oc).
> Integration tests for OpenShift Node.js debugger
> -------------------------------------------------
>
> Key: JBIDE-23321
> URL: https://issues.jboss.org/browse/JBIDE-23321
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: javascript, openshift
> Affects Versions: 4.4.2.AM1
> Reporter: Ilya Buziuk
> Assignee: Pavol Srna
> Fix For: 4.4.2.Final
>
>
> Node.js Debugging support implemented as part of https://issues.jboss.org/browse/JBIDE-22225
> Should be covered with red deer integration tests. Basically, test coverage of Node.js Debugger facilities already covered with red deer in JSDT project - https://git.eclipse.org/r/#/c/82836/
> However, implementing smth. similar for OpenShift will be much trickier. Basically, there is an integration test *org.jboss.tools.openshift.ui.bot.test.application.v3.adapter.PublishChangesTest* which is used for server adapter publishing. For now this test is not sustainable due to https://issues.jboss.org/browse/JBIDE-23005 .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months