[JBoss JIRA] (JBIDE-23384) Include integration-tests in staging and stable update sites
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23384?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-23384:
---------------------------------------
I think it would probably still make sense to have a stable repo of the integration-tests available since it's formally part of the release. But with the new approach in place, it's not blocking me anymore. (Once I apply this change to the 4.4.1.x branch.)
> 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: Nick Boldt
>
> 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
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBIDE-23377) Fix EAP integration tests - wrong cleanup
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23377?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-23377.
---------------------------------
> Fix EAP integration tests - wrong cleanup
> -----------------------------------------
>
> Key: JBIDE-23377
> URL: https://issues.jboss.org/browse/JBIDE-23377
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: integration-tests
> Affects Versions: 4.4.2.AM2
> Reporter: Martin Malina
> Assignee: Martin Malina
> Fix For: 4.4.2.AM2
>
>
> EAP integration tests fail because of change in RedDeer.
> The test suite is set up as follows:
> {code}
> @Suite.SuiteClasses({
> CreateEAP7Server.class,
> OperateEAP7Server.class,
> DeployJSPProjectEAP7Server.class,
> HotDeployJSPFileEAP7Server.class,
> UndeployJSPProjectEAP7Server.class,
> DeleteServerEAP7Server.class
> })
> {code}
> DeployJSPProject, HotDeployJSPFile and UndeployJSPProject depend on each other - they require to start in the state where the previous test left it.
> But a change in RedDeer caused that by default each test cleans up after being run now.
> So we need to add cleanup=false in the server requirement annotation for these test classes, such as:
> {code}
> @JBossServer(state=ServerReqState.RUNNING, type=ServerReqType.EAP7x, version=ServerReqVersion.EQUAL,cleanup=false)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBIDE-23384) Include integration-tests in staging and stable update sites
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23384?page=com.atlassian.jira.plugi... ]
Martin Malina edited comment on JBIDE-23384 at 10/18/16 8:00 AM:
-----------------------------------------------------------------
I came up with another possible solution:
What if we have a way of running a single test bundle from with the root directory - a way to say that I don't want all modules from tests/pom.xml, but only one.
We could create a couple profiles in the tests pom - by default, all modules will be included. But using a parameter you can select a single module.
This way, you will never have to worry about integration-tests repo as all of plugins/ would always be included in the reactor. (The only problem would be if tests depend on other tests. I don't think that really happens.)
Here's the PR for this:
https://github.com/jbosstools/jbosstools-integration-tests/pull/1641
was (Author: mmalina):
I came up with another possible solution:
What if we have a way of running a single test bundle from with the root directory - a way to say that I don't want all modules from tests/pom.xml, but only one.
We could create a couple profiles in the tests pom - by default, all modules will be included. But using a parameter you can select a single module.
> 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: Nick Boldt
>
> 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
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBIDE-23358) OpenShift Explorer: Pod status is not reflecting reality
by Dmitrii Bocharov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23358?page=com.atlassian.jira.plugi... ]
Dmitrii Bocharov reassigned JBIDE-23358:
----------------------------------------
Story Points: 8
Sprint: devex #122 October 2016
Assignee: Dmitrii Bocharov
> OpenShift Explorer: Pod status is not reflecting reality
> --------------------------------------------------------
>
> Key: JBIDE-23358
> URL: https://issues.jboss.org/browse/JBIDE-23358
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.2.AM2
> Reporter: Marián Labuda
> Assignee: Dmitrii Bocharov
> Labels: openshift_v3
> Fix For: 4.4.x
>
> Attachments: pod_status.png
>
>
> When I have a pod with failed status, it is not correctly displayed in tooling. Pod under a service has status Running (as styled next next to tree item as well as property value in property view). Current status is failed, precisely "Crash loop back off" (happens often when there are problems with fetching an image...). The correct status is shown in Web-UI as well as from oc binary "oc get pods". Refresh of a project or service does not help.
> !pod_status.png!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBIDE-23384) Include integration-tests in staging and stable update sites
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23384?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-23384:
---------------------------------------
I came up with another possible solution:
What if we have a way of running a single test bundle from with the root directory - a way to say that I don't want all modules from tests/pom.xml, but only one.
We could create a couple profiles in the tests pom - by default, all modules will be included. But using a parameter you can select a single module.
> 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: Nick Boldt
>
> 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
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBIDE-23385) IllegalArgumentException when creating new JSF project
by Radim Hopp (JIRA)
Radim Hopp created JBIDE-23385:
----------------------------------
Summary: IllegalArgumentException when creating new JSF project
Key: JBIDE-23385
URL: https://issues.jboss.org/browse/JBIDE-23385
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: jsf
Affects Versions: 4.4.2.AM2
Environment: Devstudio 10.2.0.AM2
Reporter: Radim Hopp
This is not reproducible allways (~1 out of 10).
When creating new JSF project (File->New->Other.. -> JBoss Tools Web ->JSF Project), sometimes I get
{noformat:title=can not connect() without a document}java.lang.IllegalArgumentException: can not connect() without a document
at org.eclipse.wst.sse.core.internal.FileBufferModelManager.connect(FileBufferModelManager.java:506)
at org.eclipse.wst.sse.core.internal.model.ModelManagerImpl._incrCount(ModelManagerImpl.java:672)
at org.eclipse.wst.sse.core.internal.model.ModelManagerImpl.getExistingModelForRead(ModelManagerImpl.java:1327)
at org.eclipse.wst.sse.core.internal.model.ModelManagerImpl.getExistingModelForRead(ModelManagerImpl.java:1274)
at org.jboss.tools.common.text.ext.util.StructuredModelWrapper.init(StructuredModelWrapper.java:64)
at org.jboss.tools.jsf.model.JSFMessageELCompletionEngine.getPageLocale(JSFMessageELCompletionEngine.java:600)
at org.jboss.tools.jsf.model.JSFMessageELCompletionEngine.processMessagePropertySegment(JSFMessageELCompletionEngine.java:553)
at org.jboss.tools.jsf.model.JSFMessageELCompletionEngine.resolveLastSegment(JSFMessageELCompletionEngine.java:426)
at org.jboss.tools.jsf.model.JSFMessageELCompletionEngine.resolveELOperand(JSFMessageELCompletionEngine.java:361)
at org.jboss.tools.jsf.model.JSFMessageELCompletionEngine.resolveELOperand(JSFMessageELCompletionEngine.java:153)
at org.jboss.tools.jsf.model.JSFMessageELCompletionEngine.resolve(JSFMessageELCompletionEngine.java:139)
at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.validateElOperand(ELValidator.java:397)
at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.validateELExpression(ELValidator.java:359)
at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.validateEL(ELValidator.java:337)
at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.validateFile(ELValidator.java:304)
at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.validateAll(ELValidator.java:241)
at org.jboss.tools.common.validation.ValidatorManager.validateAll(ValidatorManager.java:165)
at org.jboss.tools.common.validation.ValidatorManager.validateInJob(ValidatorManager.java:84)
at org.eclipse.wst.validation.internal.operations.ValidatorJob.run(ValidatorJob.java:78)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
{noformat}
and
{noformat:title=release was requested on a model that was not being managed}
org.jboss.tools.common.validation.JBTValidationException: release was requested on a model that was not being managed
at org.jboss.tools.common.validation.ValidatorManager.validateAll(ValidatorManager.java:171)
at org.jboss.tools.common.validation.ValidatorManager.validateInJob(ValidatorManager.java:84)
at org.eclipse.wst.validation.internal.operations.ValidatorJob.run(ValidatorJob.java:78)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: org.eclipse.wst.sse.core.internal.util.Assert$AssertionFailedException: release was requested on a model that was not being managed
at org.eclipse.wst.sse.core.internal.util.Assert.isNotNull(Assert.java:124)
at org.eclipse.wst.sse.core.internal.model.ModelManagerImpl.releaseFromRead(ModelManagerImpl.java:1941)
at org.eclipse.wst.sse.core.internal.model.ModelManagerImpl.releaseFromRead(ModelManagerImpl.java:1796)
at org.eclipse.wst.sse.core.internal.model.AbstractStructuredModel.releaseFromRead(AbstractStructuredModel.java:1026)
at org.eclipse.wst.xml.core.internal.document.DOMModelImpl.releaseFromRead(DOMModelImpl.java:880)
at org.eclipse.wst.html.core.internal.document.DOMStyleModelImpl.releaseFromRead(DOMStyleModelImpl.java:44)
at org.jboss.tools.common.text.ext.util.StructuredModelWrapper.dispose(StructuredModelWrapper.java:89)
at org.jboss.tools.jsf.model.JSFMessageELCompletionEngine.getPageLocale(JSFMessageELCompletionEngine.java:627)
at org.jboss.tools.jsf.model.JSFMessageELCompletionEngine.processMessagePropertySegment(JSFMessageELCompletionEngine.java:553)
at org.jboss.tools.jsf.model.JSFMessageELCompletionEngine.resolveLastSegment(JSFMessageELCompletionEngine.java:426)
at org.jboss.tools.jsf.model.JSFMessageELCompletionEngine.resolveELOperand(JSFMessageELCompletionEngine.java:361)
at org.jboss.tools.jsf.model.JSFMessageELCompletionEngine.resolveELOperand(JSFMessageELCompletionEngine.java:153)
at org.jboss.tools.jsf.model.JSFMessageELCompletionEngine.resolve(JSFMessageELCompletionEngine.java:139)
at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.validateElOperand(ELValidator.java:397)
at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.validateELExpression(ELValidator.java:359)
at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.validateEL(ELValidator.java:337)
at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.validateFile(ELValidator.java:304)
at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.validateAll(ELValidator.java:241)
at org.jboss.tools.common.validation.ValidatorManager.validateAll(ValidatorManager.java:165)
... 3 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBIDE-23384) Include integration-tests in staging and stable update sites
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23384?page=com.atlassian.jira.plugi... ]
Martin Malina updated JBIDE-23384:
----------------------------------
Description:
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.
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 that 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 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 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: Nick Boldt
>
> 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
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBIDE-23384) Include integration-tests in staging and stable update sites
by Martin Malina (JIRA)
Martin Malina created JBIDE-23384:
-------------------------------------
Summary: 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: Nick Boldt
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 that 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 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
(v6.4.11#64026)
9 years, 5 months