[JBoss JIRA] (JBIDE-26064) Submit a patch that avoids Windows update to run as it is being re-enabled out of user control
by Ondrej Dockal (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26064?page=com.atlassian.jira.plugi... ]
Ondrej Dockal updated JBIDE-26064:
----------------------------------
Sprint: devex #150 June 2018
> Submit a patch that avoids Windows update to run as it is being re-enabled out of user control
> ----------------------------------------------------------------------------------------------
>
> Key: JBIDE-26064
> URL: https://issues.jboss.org/browse/JBIDE-26064
> Project: Tools (JBoss Tools)
> Issue Type: Patch
> Components: integration-tests, qa
> Affects Versions: 4.6.0.AM2
> Environment: Openstack windows machines (8.1 and 10)
> Reporter: Ondrej Dockal
> Assignee: Ondrej Dockal
> Priority: Critical
> Labels: jenkins, openstack, qa
> Fix For: 4.6.0.AM3
>
>
> Due to occasional (probably periodical, dependent on system time, ie., midnight) re-enabling of windows update service, we still encounter ClosedChannelException on windows slaves on jenkinks.
> Patch will be provided, test job set up and monitored.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (JBIDE-26071) Add server adapter for WildFly 13
by Martin Malina (JIRA)
Martin Malina created JBIDE-26071:
-------------------------------------
Summary: Add server adapter for WildFly 13
Key: JBIDE-26071
URL: https://issues.jboss.org/browse/JBIDE-26071
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: server
Affects Versions: 4.6.0.AM2
Reporter: Martin Malina
It turns out WildFly 13 was released yesterday. They're on a quarterly release cadence now apparently. So I wonder how we should deal with this. Perhaps should group some of the versions if there are no breaking changes for us? Or do you think it's better to stick with our current model of always adding a new adapter and that way you can always update the libs?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (JBIDE-26071) Add server adapter for WildFly 13
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26071?page=com.atlassian.jira.plugi... ]
Martin Malina reassigned JBIDE-26071:
-------------------------------------
Assignee: Rob Stryker
> Add server adapter for WildFly 13
> ---------------------------------
>
> Key: JBIDE-26071
> URL: https://issues.jboss.org/browse/JBIDE-26071
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.6.0.AM2
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> It turns out WildFly 13 was released yesterday. They're on a quarterly release cadence now apparently. So I wonder how we should deal with this. Perhaps should group some of the versions if there are no breaking changes for us? Or do you think it's better to stick with our current model of always adding a new adapter and that way you can always update the libs?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (JBIDE-26035) Convert SSP to function in an osgi environment
by Pavol Srna (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26035?page=com.atlassian.jira.plugi... ]
Pavol Srna commented on JBIDE-26035:
------------------------------------
Thanks for your clarifications. Makes sense.
> Convert SSP to function in an osgi environment
> ----------------------------------------------
>
> Key: JBIDE-26035
> URL: https://issues.jboss.org/browse/JBIDE-26035
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: stack-server-protocol
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.6.0.AM2
>
>
> {code}
> mkdir felix
> cd felix
> wget http://download.nextag.com/apache/felix/org.apache.felix.main.distributio...
> unzip org.apache.felix.main.distribution-5.6.10.zip
> cd ../
> git clone git@github.com:robstryker/org.jboss.tools.ssp.git
> cd org.jboss.tools.ssp
> git checkout osgi_branch1
> mvn clean install
> #cp api/target/org.jboss.tools.ssp.api-0.8-SNAPSHOT.jar ../felix/felix-framework-5.6.10/bundle/
> #cp launching/target/org.jboss.tools.ssp.launching-0.8-SNAPSHOT.jar ../felix/felix-framework-5.6.10/bundle
> #cp server-spi/target/org.jboss.tools.ssp.server.spi-0.8-SNAPSHOT.jar ../felix/felix-framework-5.6.10/bundle/
> #cp server/target/org.jboss.tools.ssp.server-0.8-SNAPSHOT.jar ../felix/felix-framework-5.6.10/bundle/
> du -ah | grep "jar$" | grep "target/" | grep -v "test-classes" | grep -v "classes/" | grep -v "schema" | grep -v "client" | cut -c 1,2,3,4 --complement | awk '{ print "cp " $0 " ../felix/felix-framework-5.6.10/bundle/";}' | sh
> cd ../felix/felix-framework-5.6.10/
> java -jar bin/felix.jar
> {code}
> Note error:
> API Bundle Started
> Launching Bundle Started
> Server bundle started
> ERROR: Bundle org.jboss.tools.ssp.server.wildfly [11] Error starting file:/home/rob/tmp/ssp_osgi/felix/felix-framework-5.6.10/bundle/org.jboss.tools.ssp.server.wildfly-0.8-SNAPSHOT.jar (org.osgi.framework.BundleException: Activator start error in bundle org.jboss.tools.ssp.server.wildfly [11].)
> java.lang.NoClassDefFoundError: org/osgi/framework/BundleActivator
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1007)
> This is very strange. All the other bundles start fine. This bundle can't even find its osgi classes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months