[JBoss JIRA] (JBIDE-24704) Add Win7 with pre-installed virtualbox as template into jenkins for cdk3 testing
by Ondrej Dockal (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24704?page=com.atlassian.jira.plugi... ]
Ondrej Dockal resolved JBIDE-24704.
-----------------------------------
Resolution: Done
> Add Win7 with pre-installed virtualbox as template into jenkins for cdk3 testing
> --------------------------------------------------------------------------------
>
> Key: JBIDE-24704
> URL: https://issues.jboss.org/browse/JBIDE-24704
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: integration-tests, qa
> Affects Versions: 4.5.0.AM2
> Reporter: Ondrej Dockal
> Assignee: Ondrej Dockal
> Labels: cdk, central-ci, jenkins
> Fix For: 4.5.0.Final
>
>
> It was found out, that cdk3 can be started in CLI on win7-x64 slave with pre-installed virtualbox in central ci env. and so, I am planning to:
> * prepare machine as a new snapshot in openstack images section, tune possible bugs
> * create new template/label in jenkins for this machine
> * create a job in jenkins that would test cdk3 start up on this slave
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBDS-3588) Central shows 'Early access installed' after installing SOA 5.x Development
by Josef Kopriva (JIRA)
[ https://issues.jboss.org/browse/JBDS-3588?page=com.atlassian.jira.plugin.... ]
Josef Kopriva closed JBDS-3588.
-------------------------------
Closing - issue is no longer reproducible.
Verified in:
Red Hat JBoss Developer Studio
Version: 11.0.0.GA
Build id: GA-v20170725-0331-B596
Build date: 20170725-0331
> Central shows 'Early access installed' after installing SOA 5.x Development
> ---------------------------------------------------------------------------
>
> Key: JBDS-3588
> URL: https://issues.jboss.org/browse/JBDS-3588
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: central
> Affects Versions: 9.1.0.Beta2
> Reporter: Jan Richter
> Assignee: Paul Leacu
> Priority: Minor
> Fix For: 10.4.0.GA, 11.0.0.GA
>
>
> JBoss SOA 5.x Development feature is not shown as early access in the software/update list. Still, when installed, the welcome page will say that early access is installed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-24184) Server adapter: DEV_MODE, DEBUG_MODE, DEBUG_PORT keys (and default values) are hard-coded, not read from docker image
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24184?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-24184:
-------------------------------
Sprint: (was: devex #135 July 2017)
> Server adapter: DEV_MODE, DEBUG_MODE, DEBUG_PORT keys (and default values) are hard-coded, not read from docker image
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-24184
> URL: https://issues.jboss.org/browse/JBIDE-24184
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.4.AM2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: openshift_v3, server_adapter
> Fix For: 4.5.0.Final
>
>
> to turn on/off debugging and dev_mode for an app, one needs to set env variables. The keys that are used to set the values are all defined in the docker image labels (inspectable by doing {code}docker inspect <docker-image-id>{code}:
> * nodejs
> {code}
> "Labels": {
> ...
> "com.redhat.dev-mode": "DEV_MODE:false",
> "com.redhat.dev-mode.port": "DEBUG_PORT:5858",
> ...
> {code}
> * eap
> {code}
> "Labels": {
> ...
> "com.redhat.dev-mode": "DEBUG:true",
> "com.redhat.dev-mode.port": "DEBUG_PORT:8787",
> ...
> {code}
> Our code on the other hand is hard-coding these, not reading the keys from the docker image:
> {code}
> public class OpenShiftDebugUtils {
> private static final String DEBUG_KEY = "DEBUG";
> private static final String DEBUG_PORT_KEY = "DEBUG_PORT";
> ...
> {code}
> {code}
> public class OpenShiftLaunchController extends AbstractSubsystemController
> implements ISubsystemController, ILaunchServerController {
> ...
> private static final String DEV_MODE = "DEV_MODE"; //$NON-NLS-1$
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-19182) Incremental Publish after Full Publish WRT dodeploy markers
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19182?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-19182.
---------------------------------
Closing.
> Incremental Publish after Full Publish WRT dodeploy markers
> -----------------------------------------------------------
>
> Key: JBIDE-19182
> URL: https://issues.jboss.org/browse/JBIDE-19182
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Final
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.5.0.AM1
>
>
> THis issue is opened in regards to comments by [~dlmiles] on https://issues.jboss.org/browse/JBIDE-18862
> I am saying you should block all 'deployment directory' file modifications when you know the AS is busy using the 'deployment directory' to "deploy" (a.k.a. starting) or "undeploy" (a.k.a. stopping) of a module (or the AS itself is starting/stopping in certain scenarios). Ideally you use a file watcher API when available so there is no busy/wait loop adding additional milliseconds of delays because the wait part is never instant.
> But in an example scenario where you perform a Full Publish then 2 additional Incremental Publish ops immediately after, there is no reason to block the incrementals if you know the AS has not picked up the original Full Publish yet. You can effectively merge those two incrementals into the full publish operation behind the back of the AS.
> But you are presented with a race scenario, you have already laid down the *.dodeploy at the end of the original Full Publish. So Eclipse needs to effectively notice that scenario exists, revoke and remember that instruction to the AS in an atomic way (what I mean by this is Eclipse knows for sure if it cancelled it in time, or if it was too late and the AS got to the full publish first and started deploying).
> You need to do this so Eclipse can make file change modifications to the 'deployment directory' again.
> Once Eclipse has completed the file change operations, if takes that remembered state and puts back the *.dodeploy file (even though this is an Incremental Publish operation). You can think of this like a "save state" and "restore state" pattern if that helps. Or you can think of this like the Eclipse target goal state for the AS (such as "AS:started" and "module.abc:started") is compared to the actual AS state (such as "AS: started" and "module.abc:stopped"), and Eclipse then brings them into alignment to do this it realizes it needs to lay down the *.dodeploy marker file (even though this is an incremental publish).
> I think with the current marker file arrangements there maybe a tiny window of time where Eclipse IDE will get things wrong in respect of the AS ? But maybe ensuring both Eclipse IDE and the AS check the return value of the file delete for *.dodeploy whomever was successful in deleting the file wins, whichever party got the error "No Such File" loses and performs a rollback/cleanup of the situation to ensure it tries again soon.
> So you can speak for the JBIDE side but can someone check the AS side ? File#delete(new File("foobar.dodeploy")) != true. The AS has to delete the command instruction file before it starts to process that command, but after it has laid down a state change file (*.isdeploying).
> One of the goals of the marker files is that at no point in time is there a snapshot of the files that exist in the directory; that would leave an observer to interpret the wrong state. For example deleting one marker file before laying down the next would be bad, because there is a snapshot of time when no state marker file exists in the directory, leaving the observer to interpret that nothing is happening with that module. The alternative is to lay both the new file first then delete the old one, now there is a window of time when 2 marker files indicate state for 1 module, this is good and valid since the observer can clearly see the correct state.
> So if you got here and are still with me, then you can see how things should only slow down, when they need to slow down.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months