[JBoss JIRA] (JBDS-4192) Error Logging in devsuite-1.1.0-GA-bundle-installer.exe
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-4192?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-4192:
-------------------------------------
[~dhladky]yes, problem is there is proxy in customer network and installer is not properly report the problem.
> Error Logging in devsuite-1.1.0-GA-bundle-installer.exe
> -------------------------------------------------------
>
> Key: JBDS-4192
> URL: https://issues.jboss.org/browse/JBDS-4192
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 10.1.0.GA
> Reporter: David Hladky
> Assignee: Denis Golovin
> Priority: Critical
>
> I was contacted twice about similar problem: RHDENG-917. I am not able to find any bad activity in DM log so I need to know what might be wrong (e.g. some curl command to emulate what is goingon).
> Note: lately there was a problem with credential checking on DM using "http". If you are doing it, this is the problem. Please, let me know what it could be. Thank you.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JBDS-4201) CLI-only installation is available but does not provide necessary info
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4201?page=com.atlassian.jira.plugin.... ]
Nick Boldt edited comment on JBDS-4201 at 11/28/16 10:01 AM:
-------------------------------------------------------------
In terms of the history of the use of the InstallConfigRecord.xml file, this has been documented & supported as the simplest approach to headless / scripted installation since devstudio 8.0:
https://devstudio.redhat.com/download/scripted-install/
I can update that page to use the new devstudio naming convention and css styling.
was (Author: nickboldt):
In terms of the history of the use of the InstallConfigRecord.xml file, this has been documented & supported as the simplest approach to headless / scripted installation since devstudio 8.0:
https://devstudio.redhat.com/download/scripted-install/
> CLI-only installation is available but does not provide necessary info
> ----------------------------------------------------------------------
>
> Key: JBDS-4201
> URL: https://issues.jboss.org/browse/JBDS-4201
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Enhancement
> Components: installer
> Affects Versions: 10.2.0.GA
> Reporter: Misha Ali
> Assignee: Denis Golovin
> Fix For: 10.x
>
> Attachments: InstallConfigRecord.xml
>
>
> I had some feedback from another writer testing a procedure with devstudio. He was using a CLI-only VM and was confused because the installer worked but offered little information, as would be expected.
> Essentially, the non-GUI installation worked (java -jar devstudio_version.jar) but did not ask where to install devstudio, nor did it provide the default target folder it used. The GUI version asks if the user wants to deploy devstudio after the installation, but the non-GUI version does nothing. The resulting user experience was confusion, not knowing where devstudio was installed or how to start it.
> My questions here are:
> - is the non-GUI way a valid installation path? If yes, we should document it, and if not, we should mention it, either in the docs or when installation happens.
> - If the non-GUI installation is a valid path, it should replicate the questions in the wizard, such as where to install devstudio and which jdk to use, etc. The difference between the two installation paths causes confusion.
> Any thoughts?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JBDS-4201) CLI-only installation is available but does not provide necessary info
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4201?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-4201:
----------------------------------
In terms of the history of the use of the InstallConfigRecord.xml file, this has been documented & supported as the simplest approach to headless / scripted installation since devstudio 8.0:
https://devstudio.redhat.com/download/scripted-install/
> CLI-only installation is available but does not provide necessary info
> ----------------------------------------------------------------------
>
> Key: JBDS-4201
> URL: https://issues.jboss.org/browse/JBDS-4201
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Enhancement
> Components: installer
> Affects Versions: 10.2.0.GA
> Reporter: Misha Ali
> Assignee: Denis Golovin
> Fix For: 10.x
>
> Attachments: InstallConfigRecord.xml
>
>
> I had some feedback from another writer testing a procedure with devstudio. He was using a CLI-only VM and was confused because the installer worked but offered little information, as would be expected.
> Essentially, the non-GUI installation worked (java -jar devstudio_version.jar) but did not ask where to install devstudio, nor did it provide the default target folder it used. The GUI version asks if the user wants to deploy devstudio after the installation, but the non-GUI version does nothing. The resulting user experience was confusion, not knowing where devstudio was installed or how to start it.
> My questions here are:
> - is the non-GUI way a valid installation path? If yes, we should document it, and if not, we should mention it, either in the docs or when installation happens.
> - If the non-GUI installation is a valid path, it should replicate the questions in the wizard, such as where to install devstudio and which jdk to use, etc. The difference between the two installation paths causes confusion.
> Any thoughts?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JBIDE-23566) Include integration-tests zip in staging and stable update sites
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23566?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-23566:
-------------------------------
Description: Cloned from JBIDE-23384 to add the integration-tests ZIP file to the staging/stable sites. (was: This will allow us the use case of running integration tests against the latest release of devstudio. This use case is required by EAP QE running our tests against their EAP development builds.
Currently we have this repo:
http://download.jboss.org/jbosstools/neon/snapshots/updates/integration-t...
We're referencing it from our root pom:
https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po...
And set up a repository definition for it.
This allows us to run an individual test bundle.
This is mostly useful to satisfy test dependencies - tests depend on RedDeer as a whole which is in the target platform. But most tests also have a RedDeer extension in the plugins directory:
https://github.com/jbosstools/jbosstools-integration-tests/tree/master/pl...
With that, let's move on to why it would be useful to have a stable repo for this, e.g. http://download.jboss.org/jbosstools/neon/stable/updates/integration-tests/
Imagine you want to run integration tests against the latest stable build. If you just checkout the integration tests and run a test plugin (using mvn verify), it will use everything from the latest nightly repos.
So to use latest stable release (jbt 4.4.1.Final / devstudio 10.1.0.GA), you need a couple of things:
1. Checkout the corresponding branch of the integration tests - jbosstools-4.4.1.x in this case
2. Make sure the proper devstudio is used to test against:
https://github.com/jbosstools/jbosstools-integration-tests/blob/master/te...
-Ddevstudio.repository=https://devstudio.redhat.com/10.0/stable/updates
This also includes the TP, so RedDeer should be the correct version
3. Make sure the proper integration-tests repo is used for dependencies
Now this is what we currently don't have. Our root pom will set up the snapshots repo:
https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po...
So that's why I would like to have a stable repo of this which I could use.
There is a workaround - run "mvn install" on the whole integration-tests repo before you run your test. This will install the correct version in your local repo and that may be then used by your test. But maven will probably still prefer the newer versions from the snapshots repo that is set up in the pom.
To give you an example what can break when you use the newest org.jboss.ide.eclipse.as.reddeer plugin, but run the EAP tests against devstudio 10.1.0.GA:
The EAP 7 server adapter had 7.0 in the type name in 10.1.0.GA, but in current master it's 7.x (to accommodate for the upcoming EAP 7.1). So if you want to test EAP 7.0.1 CP candidate build against devstudio 10.1.0.GA it will fail on this.
Sorry for the lengthy explanation, but I hope it's now clear why I'm requesting this.
Also, I'd be happy to hear if you have some suggestions how to do it differently.)
> Include integration-tests zip in staging and stable update sites
> ----------------------------------------------------------------
>
> Key: JBIDE-23566
> URL: https://issues.jboss.org/browse/JBIDE-23566
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: updatesite
> Affects Versions: 4.4.2.AM2
> Reporter: Martin Malina
> Assignee: Martin Malina
> Fix For: 4.4.3.AM1
>
>
> Cloned from JBIDE-23384 to add the integration-tests ZIP file to the staging/stable sites.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JBIDE-23384) Include integration-tests (update site only) in staging and stable update sites
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23384?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-23384:
-------------------------------
Summary: Include integration-tests (update site only) in staging and stable update sites (was: Include integration-tests in staging and stable update sites)
> Include integration-tests (update site only) in staging and stable update sites
> -------------------------------------------------------------------------------
>
> Key: JBIDE-23384
> URL: https://issues.jboss.org/browse/JBIDE-23384
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: updatesite
> Affects Versions: 4.4.2.AM2
> Reporter: Martin Malina
> Assignee: Martin Malina
> Fix For: 4.4.2.Final
>
>
> This will allow us the use case of running integration tests against the latest release of devstudio. This use case is required by EAP QE running our tests against their EAP development builds.
> Currently we have this repo:
> http://download.jboss.org/jbosstools/neon/snapshots/updates/integration-t...
> We're referencing it from our root pom:
> https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po...
> And set up a repository definition for it.
> This allows us to run an individual test bundle.
> This is mostly useful to satisfy test dependencies - tests depend on RedDeer as a whole which is in the target platform. But most tests also have a RedDeer extension in the plugins directory:
> https://github.com/jbosstools/jbosstools-integration-tests/tree/master/pl...
> With that, let's move on to why it would be useful to have a stable repo for this, e.g. http://download.jboss.org/jbosstools/neon/stable/updates/integration-tests/
> Imagine you want to run integration tests against the latest stable build. If you just checkout the integration tests and run a test plugin (using mvn verify), it will use everything from the latest nightly repos.
> So to use latest stable release (jbt 4.4.1.Final / devstudio 10.1.0.GA), you need a couple of things:
> 1. Checkout the corresponding branch of the integration tests - jbosstools-4.4.1.x in this case
> 2. Make sure the proper devstudio is used to test against:
> https://github.com/jbosstools/jbosstools-integration-tests/blob/master/te...
> -Ddevstudio.repository=https://devstudio.redhat.com/10.0/stable/updates
> This also includes the TP, so RedDeer should be the correct version
> 3. Make sure the proper integration-tests repo is used for dependencies
> Now this is what we currently don't have. Our root pom will set up the snapshots repo:
> https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po...
> So that's why I would like to have a stable repo of this which I could use.
> There is a workaround - run "mvn install" on the whole integration-tests repo before you run your test. This will install the correct version in your local repo and that may be then used by your test. But maven will probably still prefer the newer versions from the snapshots repo that is set up in the pom.
> To give you an example what can break when you use the newest org.jboss.ide.eclipse.as.reddeer plugin, but run the EAP tests against devstudio 10.1.0.GA:
> The EAP 7 server adapter had 7.0 in the type name in 10.1.0.GA, but in current master it's 7.x (to accommodate for the upcoming EAP 7.1). So if you want to test EAP 7.0.1 CP candidate build against devstudio 10.1.0.GA it will fail on this.
> Sorry for the lengthy explanation, but I hope it's now clear why I'm requesting this.
> Also, I'd be happy to hear if you have some suggestions how to do it differently.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JBIDE-23384) Include integration-tests in staging and stable update sites
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23384?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-23384 at 11/28/16 9:56 AM:
--------------------------------------------------------------
I've moved the PR request to a second issue so that this one can be closed for 4.4.2.Final and the addition of the zip can be done in 4.4.3.AM1.
was (Author: nickboldt):
Let me know when you've merged the PR
> Include integration-tests in staging and stable update sites
> ------------------------------------------------------------
>
> Key: JBIDE-23384
> URL: https://issues.jboss.org/browse/JBIDE-23384
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: updatesite
> Affects Versions: 4.4.2.AM2
> Reporter: Martin Malina
> Assignee: Martin Malina
> Fix For: 4.4.2.Final
>
>
> This will allow us the use case of running integration tests against the latest release of devstudio. This use case is required by EAP QE running our tests against their EAP development builds.
> Currently we have this repo:
> http://download.jboss.org/jbosstools/neon/snapshots/updates/integration-t...
> We're referencing it from our root pom:
> https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po...
> And set up a repository definition for it.
> This allows us to run an individual test bundle.
> This is mostly useful to satisfy test dependencies - tests depend on RedDeer as a whole which is in the target platform. But most tests also have a RedDeer extension in the plugins directory:
> https://github.com/jbosstools/jbosstools-integration-tests/tree/master/pl...
> With that, let's move on to why it would be useful to have a stable repo for this, e.g. http://download.jboss.org/jbosstools/neon/stable/updates/integration-tests/
> Imagine you want to run integration tests against the latest stable build. If you just checkout the integration tests and run a test plugin (using mvn verify), it will use everything from the latest nightly repos.
> So to use latest stable release (jbt 4.4.1.Final / devstudio 10.1.0.GA), you need a couple of things:
> 1. Checkout the corresponding branch of the integration tests - jbosstools-4.4.1.x in this case
> 2. Make sure the proper devstudio is used to test against:
> https://github.com/jbosstools/jbosstools-integration-tests/blob/master/te...
> -Ddevstudio.repository=https://devstudio.redhat.com/10.0/stable/updates
> This also includes the TP, so RedDeer should be the correct version
> 3. Make sure the proper integration-tests repo is used for dependencies
> Now this is what we currently don't have. Our root pom will set up the snapshots repo:
> https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po...
> So that's why I would like to have a stable repo of this which I could use.
> There is a workaround - run "mvn install" on the whole integration-tests repo before you run your test. This will install the correct version in your local repo and that may be then used by your test. But maven will probably still prefer the newer versions from the snapshots repo that is set up in the pom.
> To give you an example what can break when you use the newest org.jboss.ide.eclipse.as.reddeer plugin, but run the EAP tests against devstudio 10.1.0.GA:
> The EAP 7 server adapter had 7.0 in the type name in 10.1.0.GA, but in current master it's 7.x (to accommodate for the upcoming EAP 7.1). So if you want to test EAP 7.0.1 CP candidate build against devstudio 10.1.0.GA it will fail on this.
> Sorry for the lengthy explanation, but I hope it's now clear why I'm requesting this.
> Also, I'd be happy to hear if you have some suggestions how to do it differently.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JBIDE-23566) Include integration-tests zip in staging and stable update sites
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23566?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-23566:
------------------------------------
I've added support for publishing the integration-tests site as part of staging (and release, too) - fixed in JBIDE-23384.
However, I noticed that you don't publish a repository.zip file like the other jbt aggregates. If you want that, you'll need to apply this PR, then I can make some tweaks to the stage/check jobs to ensure the repository.zip is copied from snapshots -> staging, verified, and then later copied from staging -> development.
https://github.com/jbosstools/jbosstools-integration-tests/pull/1673
Currently verifying the PR works in this temporary job which builds from my fork:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-integrati...
Which publishes here:
http://download.jboss.org/jbosstools/neon/snapshots/builds/jbosstools-int...
And the zip is:
http://download.jboss.org/jbosstools/neon/snapshots/builds/jbosstools-int...
So the PR works. If you want to include a zip when staging/releasing, apply this and let me know.
> Include integration-tests zip in staging and stable update sites
> ----------------------------------------------------------------
>
> Key: JBIDE-23566
> URL: https://issues.jboss.org/browse/JBIDE-23566
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: updatesite
> Affects Versions: 4.4.2.AM2
> Reporter: Martin Malina
> Assignee: Martin Malina
> Fix For: 4.4.3.AM1
>
>
> This will allow us the use case of running integration tests against the latest release of devstudio. This use case is required by EAP QE running our tests against their EAP development builds.
> Currently we have this repo:
> http://download.jboss.org/jbosstools/neon/snapshots/updates/integration-t...
> We're referencing it from our root pom:
> https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po...
> And set up a repository definition for it.
> This allows us to run an individual test bundle.
> This is mostly useful to satisfy test dependencies - tests depend on RedDeer as a whole which is in the target platform. But most tests also have a RedDeer extension in the plugins directory:
> https://github.com/jbosstools/jbosstools-integration-tests/tree/master/pl...
> With that, let's move on to why it would be useful to have a stable repo for this, e.g. http://download.jboss.org/jbosstools/neon/stable/updates/integration-tests/
> Imagine you want to run integration tests against the latest stable build. If you just checkout the integration tests and run a test plugin (using mvn verify), it will use everything from the latest nightly repos.
> So to use latest stable release (jbt 4.4.1.Final / devstudio 10.1.0.GA), you need a couple of things:
> 1. Checkout the corresponding branch of the integration tests - jbosstools-4.4.1.x in this case
> 2. Make sure the proper devstudio is used to test against:
> https://github.com/jbosstools/jbosstools-integration-tests/blob/master/te...
> -Ddevstudio.repository=https://devstudio.redhat.com/10.0/stable/updates
> This also includes the TP, so RedDeer should be the correct version
> 3. Make sure the proper integration-tests repo is used for dependencies
> Now this is what we currently don't have. Our root pom will set up the snapshots repo:
> https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po...
> So that's why I would like to have a stable repo of this which I could use.
> There is a workaround - run "mvn install" on the whole integration-tests repo before you run your test. This will install the correct version in your local repo and that may be then used by your test. But maven will probably still prefer the newer versions from the snapshots repo that is set up in the pom.
> To give you an example what can break when you use the newest org.jboss.ide.eclipse.as.reddeer plugin, but run the EAP tests against devstudio 10.1.0.GA:
> The EAP 7 server adapter had 7.0 in the type name in 10.1.0.GA, but in current master it's 7.x (to accommodate for the upcoming EAP 7.1). So if you want to test EAP 7.0.1 CP candidate build against devstudio 10.1.0.GA it will fail on this.
> Sorry for the lengthy explanation, but I hope it's now clear why I'm requesting this.
> Also, I'd be happy to hear if you have some suggestions how to do it differently.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JBIDE-23566) Include integration-tests zip in staging and stable update sites
by Nick Boldt (JIRA)
Nick Boldt created JBIDE-23566:
----------------------------------
Summary: Include integration-tests zip in staging and stable update sites
Key: JBIDE-23566
URL: https://issues.jboss.org/browse/JBIDE-23566
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: updatesite
Affects Versions: 4.4.2.AM2
Reporter: Martin Malina
Assignee: Martin Malina
Fix For: 4.4.2.Final
This will allow us the use case of running integration tests against the latest release of devstudio. This use case is required by EAP QE running our tests against their EAP development builds.
Currently we have this repo:
http://download.jboss.org/jbosstools/neon/snapshots/updates/integration-t...
We're referencing it from our root pom:
https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po...
And set up a repository definition for it.
This allows us to run an individual test bundle.
This is mostly useful to satisfy test dependencies - tests depend on RedDeer as a whole which is in the target platform. But most tests also have a RedDeer extension in the plugins directory:
https://github.com/jbosstools/jbosstools-integration-tests/tree/master/pl...
With that, let's move on to why it would be useful to have a stable repo for this, e.g. http://download.jboss.org/jbosstools/neon/stable/updates/integration-tests/
Imagine you want to run integration tests against the latest stable build. If you just checkout the integration tests and run a test plugin (using mvn verify), it will use everything from the latest nightly repos.
So to use latest stable release (jbt 4.4.1.Final / devstudio 10.1.0.GA), you need a couple of things:
1. Checkout the corresponding branch of the integration tests - jbosstools-4.4.1.x in this case
2. Make sure the proper devstudio is used to test against:
https://github.com/jbosstools/jbosstools-integration-tests/blob/master/te...
-Ddevstudio.repository=https://devstudio.redhat.com/10.0/stable/updates
This also includes the TP, so RedDeer should be the correct version
3. Make sure the proper integration-tests repo is used for dependencies
Now this is what we currently don't have. Our root pom will set up the snapshots repo:
https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po...
So that's why I would like to have a stable repo of this which I could use.
There is a workaround - run "mvn install" on the whole integration-tests repo before you run your test. This will install the correct version in your local repo and that may be then used by your test. But maven will probably still prefer the newer versions from the snapshots repo that is set up in the pom.
To give you an example what can break when you use the newest org.jboss.ide.eclipse.as.reddeer plugin, but run the EAP tests against devstudio 10.1.0.GA:
The EAP 7 server adapter had 7.0 in the type name in 10.1.0.GA, but in current master it's 7.x (to accommodate for the upcoming EAP 7.1). So if you want to test EAP 7.0.1 CP candidate build against devstudio 10.1.0.GA it will fail on this.
Sorry for the lengthy explanation, but I hope it's now clear why I'm requesting this.
Also, I'd be happy to hear if you have some suggestions how to do it differently.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months