[JBoss JIRA] (JBDS-3410) devstudio not reading jbdevstudio.ini on osx
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3410?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-3410:
--------------------------------
Sprint: Sprint #3 May 2015 (was: Sprint #2 April 2015)
> devstudio not reading jbdevstudio.ini on osx
> --------------------------------------------
>
> Key: JBDS-3410
> URL: https://issues.jboss.org/browse/JBDS-3410
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 8.0.0.Alpha2
> Reporter: Max Rydahl Andersen
> Assignee: Denis Golovin
> Priority: Critical
> Fix For: 9.0.0.Beta1
>
>
> When starting on OSX it has noticable larger fonts than previous versions.
> It seems to be ignoring -Dorg.eclipse.swt.internal.carbon.smallFonts set in jbdevstudio.ini.
> comparing jbdevstudio8 vs 9 I see that in 8 the location was:
> studio/jbdevstudio.app/Contents/MacOS/jbdevstudio.ini
> but in 9 we have it at
> studio/jbdevstudio.ini
> so that could explain why it wont get picked up ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-18772) Include publish.sh in parent pom as versioned maven dependency
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18772?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-18772:
------------------------------------
I've updated the 4.3.mars jobs to use the new -Pdeploy-to-jboss.org profile.
So... are we done here?
> Include publish.sh in parent pom as versioned maven dependency
> --------------------------------------------------------------
>
> Key: JBIDE-18772
> URL: https://issues.jboss.org/browse/JBIDE-18772
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Priority: Critical
> Fix For: 4.3.0.Beta1
>
> Attachments: jbds-publish-to-snapshots.png
>
>
> instead of relying to publish.sh being on master, we should use a versioned publish.sh (or maybe even mojo) that the build then uses.
> suggestion:
> publish.sh (or mojo) gets released to our maven repo, use it in the pom.xml to perform publishing.
> What this helps with is:
> a) can do changes to publish mechanism without affecting every past builds.
> b) more movable build system
> c) isolated testing possible
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15482:
------------------------------------
Experiemental job "jbosstools-openshift_master_JBDS2741" has now been deleted as no longer required.
> Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15482
> URL: https://issues.jboss.org/browse/JBIDE-15482
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build, updatesite
> Affects Versions: 4.2.0.Beta2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Labels: f2f2014
> Fix For: 4.3.0.Alpha2
>
>
> Be it proposed:
> {quote}
> that instead of an in-place move which reuses
> generic folder names like "staging" and "staging.previous", we
> composite build output using unique names like
> 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255
> {quote}
> We therefore need:
> a) to regenerate the composite site each time there's a new build
> published, in order to remove the oldest and add the newest (keeping
> only the Nth and N-1rst builds)
> (I have a script that might already work for this, or would need
> tweaking.)
> b) heuristics to determine when an older (N-2, N-3, ... N-z) build is
> no longer needed, perhaps simply by assuming no one needs it after
> 24hrs?
> 24 hours should be more that enough.
> c) a cleanup script which can purge all but the builds which are no
> more than 1 day old, keeping at all times at least two builds (N and
> N-1)
> (I have a script that already does this for folders like
> http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but
> might need to be tweaked to work for a new pattern of
> staging/\$\{JOB_NAME}/<BUILD_ID>/ .)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19389) Cannot set timeout configuration to connect JDV server on Teiid designer
by Paul Richardson (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19389?page=com.atlassian.jira.plugi... ]
Paul Richardson commented on JBIDE-19389:
-----------------------------------------
[~rob.stryker]
Yeah. No problem. We have a JIRA open in Designer for this so will work it our end and provide a preference with the API you suggested.
> Cannot set timeout configuration to connect JDV server on Teiid designer
> ------------------------------------------------------------------------
>
> Key: JBIDE-19389
> URL: https://issues.jboss.org/browse/JBIDE-19389
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: server
> Reporter: Eiichi Nagai
> Assignee: Barry LaFond
>
> Describe the issue:
> The teiid-designer cannot connect to remote JDV server by timeout exceptions. However, the teiid-designer cannnot set timeout for it.
> {noformat}
> org.jboss.ide.eclipse.as.management.core.JBoss7ManangerException: java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to remote://XXXX:9999. The connection timed out
> at org.jboss.ide.eclipse.as.internal.management.as71.AS71Manager.execute(AS71Manager.java:336)
> at org.jboss.ide.eclipse.as.internal.management.as71.JBoss71ManagerService.execute(JBoss71ManagerService.java:171)
> at org.jboss.ide.eclipse.as.management.core.JBoss7ManagerServiceProxy.execute(JBoss7ManagerServiceProxy.java:87)
> at org.teiid.designer.runtime.adapter.JBoss7ServerUtil.executeRequest(JBoss7ServerUtil.java:66)
> at org.teiid.designer.runtime.adapter.JBoss7ServerUtil.isTeiidServer(JBoss7ServerUtil.java:192)
> at org.teiid.designer.runtime.adapter.TeiidServerAdapterFactory.adaptJBoss7Server(TeiidServerAdapterFactory.java:181)
> at org.teiid.designer.runtime.adapter.TeiidServerAdapterFactory.adaptServer(TeiidServerAdapterFactory.java:82)
> at org.teiid.designer.runtime.TeiidParentServerListener.serverChanged(TeiidParentServerListener.java:153)
> at org.eclipse.wst.server.core.internal.ServerNotificationManager.broadcastChange(ServerNotificationManager.java:125)
> at org.eclipse.wst.server.core.internal.Server.fireServerStateChangeEvent(Server.java:742)
> at org.eclipse.wst.server.core.internal.Server.setServerState(Server.java:650)
> at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.setServerState(ServerBehaviourDelegate.java:143)
> at org.jboss.ide.eclipse.as.wtp.core.server.behavior.ControllableServerBehavior.setServerStarted(ControllableServerBehavior.java:201)
> at org.jboss.tools.as.core.server.controllable.internal.DeployableServerBehavior.setServerStarted(DeployableServerBehavior.java:127)
> at org.jboss.ide.eclipse.as.rse.core.StandardRSEStartLaunchDelegate.preLaunchCheck(StandardRSEStartLaunchDelegate.java:72)
> at org.jboss.ide.eclipse.as.rse.core.subsystems.RSECommandLineLaunchController.preLaunchCheck(RSECommandLineLaunchController.java:103)
> 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)
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to remote://XXXX:9999. The connection timed out
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.ide.eclipse.as.internal.management.as71.AS71Manager.execute(AS71Manager.java:325)
> ... 23 more
> Caused by: java.net.ConnectException: JBAS012144: JBAS012144: Could not connect to remote://XXXX:9999. The connection timed out
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:131)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:176)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:144)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:115)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:98)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 25 more
> {noformat}
> Additional information:
> We want to set a property of "IAS7ManagementDetails.PROPERTY_TIMEOUT" via teiid-designer.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19463) Cannot connect to remote server in JMX Navigator
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19463?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-19463.
---------------------------------
Resolution: Rejected
org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection has the following code:
{code}
public boolean canControl() {
return server.getServerState() == IServer.STATE_STARTED && server.getRuntime() != null;
}
{code}
This behavior is correct. With no runtime, we cannot add jars to our running classpath to actually open up a proper JMX connection. We need a local runtime from which to load the required client jars for our JMX calls.
> 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, 11 months
[JBoss JIRA] (JBIDE-19328) wf8.2 in fs+rse mode with strange publish behavior (cmd line)
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19328?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-19328.
---------------------------------
Resolution: Rejected
I can't replicate this anymore. It must have been a weird fluke.
> wf8.2 in fs+rse mode with strange publish behavior (cmd line)
> -------------------------------------------------------------
>
> Key: JBIDE-19328
> URL: https://issues.jboss.org/browse/JBIDE-19328
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.3.0.Alpha1
> Reporter: Rob Stryker
>
> 1) Start with a clean wf8.2
> {code}
> rm -rf wildfly-8.2.0.Final.zip.expanded/
> cd ../zipped
> ls -1 wildfly-8.2.0.Final.zip | ./unzipAndMove.sh
> cd ../unzipped/wildfly-8.2.0.Final.zip.expanded/bin/
> ./add-user.sh
> {code}
> 2) Start server in eclipse. filesystem + rse, defaults, localhost, no changes, all standard
> Process command line appears to be as follows:
> 22608 pts/1 Sl+ 0:10 java -Dprogram.name=JBossTools: WildFly 8.x -server -Xms64m -Xmx512m -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/unzipped/wildfly-8.2.0.Final.zip.expanded/standalone/log/boot.log -Dlogging.configuration=file:/home/rob/apps/jboss/unzipped/wildfly-8.2.0.Final.zip.expanded/standalone/configuration/logging.properties -Djboss.home.dir=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.Final.zip.expanded -Dorg.jboss.logmanager.nocolor=true -jar /home/rob/apps/jboss/unzipped/wildfly-8.2.0.Final.zip.expanded/jboss-modules.jar -mp /home/rob/apps/jboss/unzipped/wildfly-8.2.0.Final.zip.expanded/modules -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.Final.zip.expanded/standalone
> 3) Copy a simple exploded web project into your deployments folder with a cp -R command. Then, touch WebProjectName.war.dodeploy to ensure it is picked up by server
> 4) Observe following sysout from server:
> 07:23:49,973 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found WebApp1.war in deployment directory. To trigger deployment create a file called WebApp1.war.dodeploy
> 07:23:53,921 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found WebApp1.war in deployment directory. To trigger deployment create a file called WebApp1.war.dodeploy
> 07:23:54,990 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "WebApp1.war" (runtime-name: "WebApp1.war")
> 07:23:55,295 INFO [org.wildfly.extension.undertow] (MSC service thread 1-16) JBAS017534: Registered web context: /WebApp1
> 07:23:55,347 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "WebApp1.war" (runtime-name : "WebApp1.war")
> 07:24:00,366 INFO [org.wildfly.extension.undertow] (MSC service thread 1-10) JBAS017535: Unregistered web context: /WebApp1
> 07:24:00,381 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-14) HV000001: Hibernate Validator 5.1.3.Final
> 07:24:00,413 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment WebApp1.war (runtime-name: WebApp1.war) in 51ms
> 07:24:00,448 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018558: Undeployed "WebApp1.war" (runtime-name: "WebApp1.war")
> 07:24:05,451 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found WebApp1.war in deployment directory. To trigger deployment create a file called WebApp1.war.dodeploy
> If we repeat but instead of starting from eclipse, we start from cmd line (standalone.sh) it seems to work, which may indicate a problem in how we're launching (?). Process details when started via standalone are as follows:
> 23536 pts/3 Sl+ 0:10 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.Final.zip.expanded/standalone/log/server.log -Dlogging.configuration=file:/home/rob/apps/jboss/unzipped/wildfly-8.2.0.Final.zip.expanded/standalone/configuration/logging.properties -jar /home/rob/apps/jboss/unzipped/wildfly-8.2.0.Final.zip.expanded/jboss-modules.jar -mp /home/rob/apps/jboss/unzipped/wildfly-8.2.0.Final.zip.expanded/modules org.jboss.as.standalone -Djboss.home.dir=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.Final.zip.expanded -Djboss.server.base.dir=/home/rob/apps/jboss/unzipped/wildfly-8.2.0.Final.zip.expanded/standalone
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19753) Investigate if Arquillian works fine with Sapphire 9.0.0
by Alexey Kazakov (JIRA)
Alexey Kazakov created JBIDE-19753:
--------------------------------------
Summary: Investigate if Arquillian works fine with Sapphire 9.0.0
Key: JBIDE-19753
URL: https://issues.jboss.org/browse/JBIDE-19753
Project: Tools (JBoss Tools)
Issue Type: Task
Components: arquillian
Reporter: Alexey Kazakov
Priority: Critical
Currently JBT TP includes Sapphire 9.0.0.201408261741 (available in Eclipse Mars M6 update site).
I just checked the latest nightly build from https://hudson.eclipse.org/sapphire/job/9.0.x/ and I see that some Sapphire API has been changed. We have compilation problems in Batch because of it.
Sapphire is gonna be updated in Mars M7 - https://www.eclipse.org/forums/index.php/t/1066214/
And we have to switch to the new API in Batch in JBT 4.3.0.Beta1 and update Sapphire in our TP.
So, we also should make sure that Arquillian supports the latest Sapphire 9.0.0.x. Otherwise we will get a problem with two components (Batch and Arquillian) which depends on two incompatible versions of Sapphire.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months