[JBoss JIRA] (JBIDE-14549) Deploying archive via drag&drop triggers server start
by Jaroslav Jankovič (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14549?page=com.atlassian.jira.plugi... ]
Jaroslav Jankovič commented on JBIDE-14549:
-------------------------------------------
I added steps for both use cases. Hope it's sufficient
> Deploying archive via drag&drop triggers server start
> -----------------------------------------------------
>
> Key: JBIDE-14549
> URL: https://issues.jboss.org/browse/JBIDE-14549
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: archives
> Affects Versions: 4.1.0.Beta1
> Reporter: Jaroslav Jankovič
> Assignee: Rob Stryker
> Fix For: 4.1.1.Final
>
>
> If archive is deployed with Publish dialog, server is (correctly) not started. However, drag&drop archive under server in servers view cause server starting.
> STEP: create a simple java project
> STEP: create an archive in it (via explorer/view)
> STEP: in Project Explorer view, expand Project Archives explorer, select the created archive and drag & drop into server in server's view
> ASSERT: archive is deployed on the server
> FAIL: server start is initiated but I think it should be not, because archive deploy via Publish Archive dialog doesn't trigger server's start
> There is another bug. When user wants to drag&drop whole project into the server, server's starting process is also initiated, but should be not.
> STEP: create a simple java project
> STEP: open Project Explorer view and drag & drop the project into a server
> ASSERT: project is deployed
> ASSERT: server is not started
> STEP: undeploy the project from a server
> STEP: create an archive in the project
> STEP: drag & drop the project into a server
> ASSERT: project is deployed
> FAIL: server's start is triggered
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBIDE-14549) Deploying archive via drag&drop triggers server start
by Jaroslav Jankovič (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14549?page=com.atlassian.jira.plugi... ]
Jaroslav Jankovič updated JBIDE-14549:
--------------------------------------
Description:
If archive is deployed with Publish dialog, server is (correctly) not started. However, drag&drop archive under server in servers view cause server starting.
STEP: create a simple java project
STEP: create an archive in it (via explorer/view)
STEP: in Project Explorer view, expand Project Archives explorer, select the created archive and drag & drop into server in server's view
ASSERT: archive is deployed on the server
FAIL: server start is initiated but I think it should be not, because archive deploy via Publish Archive dialog doesn't trigger server's start
There is another bug. When user wants to drag&drop whole project into the server, server's starting process is also initiated, but should be not.
STEP: create a simple java project
STEP: open Project Explorer view and drag & drop the project into a server
ASSERT: project is deployed
ASSERT: server is not started
STEP: undeploy the project from a server
STEP: create an archive in the project
STEP: drag & drop the project into a server
ASSERT: project is deployed
FAIL: server's start is triggered
was:
If archive is deployed with Publish dialog, server is (correctly) not started. However, drag&drop archive under server in servers view cause server starting.
There is another bug. When user wants to drag&drop whole project into the server, server's starting process is also initiated, but should be not.
> Deploying archive via drag&drop triggers server start
> -----------------------------------------------------
>
> Key: JBIDE-14549
> URL: https://issues.jboss.org/browse/JBIDE-14549
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: archives
> Affects Versions: 4.1.0.Beta1
> Reporter: Jaroslav Jankovič
> Assignee: Rob Stryker
> Fix For: 4.1.1.Final
>
>
> If archive is deployed with Publish dialog, server is (correctly) not started. However, drag&drop archive under server in servers view cause server starting.
> STEP: create a simple java project
> STEP: create an archive in it (via explorer/view)
> STEP: in Project Explorer view, expand Project Archives explorer, select the created archive and drag & drop into server in server's view
> ASSERT: archive is deployed on the server
> FAIL: server start is initiated but I think it should be not, because archive deploy via Publish Archive dialog doesn't trigger server's start
> There is another bug. When user wants to drag&drop whole project into the server, server's starting process is also initiated, but should be not.
> STEP: create a simple java project
> STEP: open Project Explorer view and drag & drop the project into a server
> ASSERT: project is deployed
> ASSERT: server is not started
> STEP: undeploy the project from a server
> STEP: create an archive in the project
> STEP: drag & drop the project into a server
> ASSERT: project is deployed
> FAIL: server's start is triggered
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBIDE-14549) Deploying archive via drag&drop triggers server start
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14549?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-14549:
--------------------------------
Fix Version/s: 4.1.1.Final
(was: 4.1.0.Beta2)
Drag and drop will try either a simple publish if possible (ie, if the node is adaptable to both an IProject and has modules registered for it), and if not, it will attempt a run-on-server action, which involves a publish but also involves starting the server and trying to load a web browser or other relevant client to show to the user.
So for example if you drag and drop a servlet file, it will attempt to run it on the server.
In the case of a plain old java project containing project archives, the root itself is converible to a project and does have a module in it, so only a publish should be initiated. My tests demonstrate this to be correct.
Can you be more specific what exactly you are dragging and dropping, what node, from what view? Please list the use-cases separately as I'm a little confused.
Either way, I'm marking this for 4.1.x.
> Deploying archive via drag&drop triggers server start
> -----------------------------------------------------
>
> Key: JBIDE-14549
> URL: https://issues.jboss.org/browse/JBIDE-14549
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: archives
> Affects Versions: 4.1.0.Beta1
> Reporter: Jaroslav Jankovič
> Assignee: Rob Stryker
> Fix For: 4.1.1.Final
>
>
> If archive is deployed with Publish dialog, server is (correctly) not started. However, drag&drop archive under server in servers view cause server starting.
> There is another bug. When user wants to drag&drop whole project into the server, server's starting process is also initiated, but should be not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBIDE-13843) Investigate use of SWTBot 2.1 (and org.junit_4.11) in target platform
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13843?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-13843:
----------------------------------------
Newer snapshot of SWTBot fixes compatibility with Junit 4.11 and Hamcrest 1.3.
Release of SWTBot should happen by the end of June (ideally same day as Kepler).
If we have issues in JBT tests because of SWTBot bug #404346, we could mirror a newer snapshot and use it in TP until the release gets out.
> Investigate use of SWTBot 2.1 (and org.junit_4.11) in target platform
> ---------------------------------------------------------------------
>
> Key: JBIDE-13843
> URL: https://issues.jboss.org/browse/JBIDE-13843
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: target-platform, testing-tools
> Affects Versions: 4.1.0.Alpha2
> Reporter: Nick Boldt
> Assignee: Len DiMaggio
> Priority: Blocker
> Fix For: 4.1.0.Beta2
>
>
> Eclipse 4.3M5a contains:
> {code}4.3milestones/S-4.3M5a-201302041400/plugins/org.junit4_4.8.1.v20120705-112236.jar{code}
> But in Eclipse 4.3M6, the only JUnit available is:
> {code}4.3milestones/S-4.3M6-201303141330/plugins/org.junit_4.11.0.v201303080030.jar{code}
> So, we need to see if a newer SWTBot can be used which depends on org.junit instead of org.junit4.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBIDE-14330) Create an OpenShift connector in the JBoss Tools discovery catalog
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14330?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-14330:
-------------------------------------
Indeed. Once a feature has been installed, it's hidden from the software page
> Create an OpenShift connector in the JBoss Tools discovery catalog
> ------------------------------------------------------------------
>
> Key: JBIDE-14330
> URL: https://issues.jboss.org/browse/JBIDE-14330
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: central
> Affects Versions: 4.1.0.Alpha2
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Labels: new_and_noteworthy
> Fix For: 4.1.0.Beta1
>
> Attachments: openshift-discovery.png
>
>
> JBoss Central will now always display the OpenShift wizard, even if not installed already (see JBIDE-13987).
> If the OpenShift feature is missing, we should install it via the discovery mechanism.
> Hence, OpenShift must be added to the JBT discovery catalog (JBDS has it installed by default)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBIDE-14677) jobs that depend on com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0-SNAPSHOT are broken as that version no longer exists
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14677?page=com.atlassian.jira.plugi... ]
Nick Boldt closed JBIDE-14677.
------------------------------
Assignee: Nick Boldt (was: Mickael Istria)
Fix Version/s: 4.1.0.Beta1
Resolution: Done
Fixed in SVN (trunk).
> jobs that depend on com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0-SNAPSHOT are broken as that version no longer exists
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-14677
> URL: https://issues.jboss.org/browse/JBIDE-14677
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng
> Affects Versions: 4.1.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.0.Beta1
>
>
> 21 jenkins jobs such as ./DevStudio/view/DevStudio_Trunk/job/jbosstools-4.1_trunk.install-tests.matrix/config.xml and ./DevStudio/view/DevStudio_Trunk/job/jbosstools-composite-install_master/config.xml, which depend on com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0-SNAPSHOT, are currently failing. I suspect this is because the 1.1.0 release has happened.
> Complete list of config.xml files containing the string "maven-download-plugin:1" are:
> {code}
> ./DevStudio/view/DevStudio_5.0.indigo/job/jbosstools-3.3_stable_branch.director-install-tests.egit.matrix/config.xml
> ./DevStudio/view/DevStudio_5.0.indigo/job/jbosstools-3.3_stable_branch.director-install-tests.m2e.matrix/config.xml
> ./DevStudio/view/DevStudio_5.0.indigo/job/jbosstools-3.3_stable_branch.install-e3.7.0-jbt_3.3.x/config.xml
> ./DevStudio/view/DevStudio_5.0.indigo/job/jbosstools-3.3_stable_branch.install-e3.7.2-jbt_3.3.0-jbt_3.3.x/config.xml
> ./DevStudio/view/DevStudio_5.0.indigo/job/jbosstools-3.3_stable_branch.install-e4.2-jbt_3.3.x/config.xml
> ./DevStudio/view/DevStudio_5.0.indigo/job/jbosstools-3.3_stable_branch.install-tests.egit.matrix/config.xml
> ./DevStudio/view/DevStudio_5.0.indigo/job/jbosstools-3.3_stable_branch.install-tests.m2e.matrix/config.xml
> ./DevStudio/view/DevStudio_6.0.juno/job/jbdevstudio-6.0_stable_branch.install-tests-e4.2-jbds_BYOE_stable_branch/config.xml
> ./DevStudio/view/DevStudio_6.0.juno/job/jbdevstudio-6.0_stable_branch.install-tests-eclipseLatest-jbds_BYOE_stable_branch/config.xml
> ./DevStudio/view/DevStudio_6.0.juno/job/jbosstools-4.0_stable_branch.install-tests-e4.2-jbt_4.0.juno/config.xml
> ./DevStudio/view/DevStudio_6.0.juno/job/jbosstools-4.0_stable_branch.install-tests-eclipseLatest-jbt_4.0.juno/config.xml
> ./DevStudio/view/DevStudio_6.0.juno/job/jbosstools-4.0_stable_branch.install-tests.matrix/config.xml
> ./DevStudio/view/DevStudio_6.0.juno/job/jbosstools-4.0_stable_branch.upgrade-tests.matrix/config.xml
> ./DevStudio/view/DevStudio_6.0.juno/job/jbosstools-composite-install_40/config.xml
> ./DevStudio/view/DevStudio_7.0.kepler/job/jbosstools-composite-install_41/config.xml
> ./DevStudio/view/DevStudio_Disabled/job/zz_disabled_jbdevstudio-7.0_trunk.install-tests-eclipseLatest-jbds_BYOE_trunk/config.xml
> ./DevStudio/view/DevStudio_Disabled/job/zz_disabled_jbosstools-4.1_trunk.install-tests-eclipseLatest-jbt_trunk/config.xml
> ./DevStudio/view/DevStudio_Trunk/job/jbosstools-4.1_trunk.install-tests-e4.3-jbt_trunk/config.xml
> ./DevStudio/view/DevStudio_Trunk/job/jbosstools-4.1_trunk.install-tests-eclipseLatest-jbt_trunk/config.xml
> ./DevStudio/view/DevStudio_Trunk/job/jbosstools-4.1_trunk.install-tests.matrix/config.xml
> ./DevStudio/view/DevStudio_Trunk/job/jbosstools-composite-install_master/config.xml
> {code}
> Can you update the above jobs to use the correct new version, either 1.2.0-SNAPSHOT or 1.1.0 ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months