[JBoss JIRA] (JBIDE-16626) OpenShift Server Adapter: Binary deployment
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16626?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen edited comment on JBIDE-16626 at 8/27/14 8:45 AM:
----------------------------------------------------------------------
[~mlabuda] we cannot call it ROOT.war by default since it will conflict with the existing project related to the openshift instance.
This is what JBIDE-14818 relates to by allowing to name the server deployments.
was (Author: maxandersen):
[~mlabuda] we cannot call it ROOT.war by default since it will conflict with the existing project related to the openshift instance.
This is what JBIDE-14818 relates to.
> OpenShift Server Adapter: Binary deployment
> -------------------------------------------
>
> Key: JBIDE-16626
> URL: https://issues.jboss.org/browse/JBIDE-16626
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.0.Final, 4.2.0.Alpha2
> Reporter: Marián Labuda
> Assignee: Andre Dietisheim
> Fix For: 4.2.x
>
>
> At first, I am not sure whether this is bug or desired behaviour (in that case this issue is Enhancement). There is a problem with binary deployment.
> Current workflow is following:
> PRESTEPS:
> 1. Create OpenShift application (e.g. EAP through OpenShift explorer, context menu, new application)
> 2. Open Project Explorer, select application and open context menu OpenShift - Configure Markers...
> 3. Select disable maven build marker. You can select also Hot deploy to improve deploying speed (no need to restart cartridge).
> 4. Open Navigator - .openshift - markers and select new markers and add them to Index (context menu - Team - Add to Index)
> 5. Push application to OpenShift (e.g. context menu of application - Team - Commit...)
> BINARY DEPLOYMENT
> 1. Now imagine, you want to binary deploy. Let's say, user change something in index.html (for example title).
> 2. Then it's required to locally build application (context menu of application - Run as - Maven build and set goal "clean package -Popenshift"). Result - application is built in deployment folder as ROOT.war.
> 3. Add ROOT.war to git index (context menu - Team - Add to index)
> 4. Drag and drop application from Project Explorer to Servers view adapter onto the given OpenShift adapter.
> 5. Confirm push.
> My idea of binary deployment is:
> 1. User change something in application
> 2. Drag and drop application from Project Explorer to Servers view onto OpenShift adapter - this step build application, add ROOT.war to index.
> 3. Confirm to push.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JBIDE-16626) OpenShift Server Adapter: Binary deployment
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16626?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-16626:
---------------------------------------------
[~mlabuda] we cannot call it ROOT.war by default since it will conflict with the existing project related to the openshift instance.
This is what JBIDE-14818 relates to.
> OpenShift Server Adapter: Binary deployment
> -------------------------------------------
>
> Key: JBIDE-16626
> URL: https://issues.jboss.org/browse/JBIDE-16626
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.0.Final, 4.2.0.Alpha2
> Reporter: Marián Labuda
> Assignee: Andre Dietisheim
> Fix For: 4.2.x
>
>
> At first, I am not sure whether this is bug or desired behaviour (in that case this issue is Enhancement). There is a problem with binary deployment.
> Current workflow is following:
> PRESTEPS:
> 1. Create OpenShift application (e.g. EAP through OpenShift explorer, context menu, new application)
> 2. Open Project Explorer, select application and open context menu OpenShift - Configure Markers...
> 3. Select disable maven build marker. You can select also Hot deploy to improve deploying speed (no need to restart cartridge).
> 4. Open Navigator - .openshift - markers and select new markers and add them to Index (context menu - Team - Add to Index)
> 5. Push application to OpenShift (e.g. context menu of application - Team - Commit...)
> BINARY DEPLOYMENT
> 1. Now imagine, you want to binary deploy. Let's say, user change something in index.html (for example title).
> 2. Then it's required to locally build application (context menu of application - Run as - Maven build and set goal "clean package -Popenshift"). Result - application is built in deployment folder as ROOT.war.
> 3. Add ROOT.war to git index (context menu - Team - Add to index)
> 4. Drag and drop application from Project Explorer to Servers view adapter onto the given OpenShift adapter.
> 5. Confirm push.
> My idea of binary deployment is:
> 1. User change something in application
> 2. Drag and drop application from Project Explorer to Servers view onto OpenShift adapter - this step build application, add ROOT.war to index.
> 3. Confirm to push.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JBIDE-17889) Provide AngularJS Eclipse IDE through JBoss Central Early Access
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17889?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-17889:
---------------------------------------------
this looks like a duplicate - [~dgolovin] ?
> Provide AngularJS Eclipse IDE through JBoss Central Early Access
> ----------------------------------------------------------------
>
> Key: JBIDE-17889
> URL: https://issues.jboss.org/browse/JBIDE-17889
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: jsp/jsf/xml/html source editing
> Affects Versions: 4.2.0.Beta3
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Priority: Blocker
> Fix For: 4.2.0.CR1
>
>
> AngularJS Eclipse IDE have no frozen API to depend on, so we have to lock version avoid installation/update to newest version from external update. We also should make sure it works with tern bundles included into JBossTools target platform.
> Proposed name for new Feature/Bundle is org.jboss.tools.jst.angularjs.editor'.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JBIDE-2720) Need 64-bit windows support
by Konstantin Marmalyukov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-2720?page=com.atlassian.jira.plugin... ]
Konstantin Marmalyukov commented on JBIDE-2720:
-----------------------------------------------
{quote}Try open a html file (not .xhtml) and open the HTML Preview view.{quote}
Or simply open HTML file in JBoss Tools html editor. To ensure you open HTML editor with preview look at the buttons in vertical toolbar, they must be different with those we have later.
!screenshot-1.png|thumbnail!
In screenshot above two files with the same content is opened.
> Need 64-bit windows support
> ---------------------------
>
> Key: JBIDE-2720
> URL: https://issues.jboss.org/browse/JBIDE-2720
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: visual-page-editor-core
> Affects Versions: 2.1.0.GA, 2.1.1, 2.1.2, 3.0.0.alpha
> Reporter: Samuel Mendenhall
> Assignee: Konstantin Marmalyukov
> Fix For: 4.2.x
>
> Attachments: .mozconfig, buildlog1.log, buildlog1_x86_short.log, buildlog2.log, buildlog2_x86_short.log, buildlog3.log, build_error_when_run_x64.bat.txt, build_log_win_sdk6.log.txt, build_log_win_sdk7.log.txt, c-runtime-error.png, mozconfig1, mozconfig2, screenshot-1.png, vpe-win-jdk64.png
>
>
> If you use a 64-bit JVM, the XULRunner parts of JBoss Tools does not load.
> We should look into providing a xulrunner for Windows 64-bit.
> *Update:*
> In JBoss Tools 4.1.0 and JBoss Developer Studio 7.0.0 XULRunner for 64-bit Windows is provided via experimental update site: http://download.jboss.org/jbosstools/updates/integration/kepler/core/xulr...
> {color:red}*Known problems:*{color}
> * XULRunner for 64-bit Windows is incompatible with Intel OpenCL SDK
> *If you get [R6034 error|https://issues.jboss.org/browse/JBIDE-2720?focusedCommentId=1277169...] you may:*
> * Try to uninstall Intel OpenCL SDK
> * *OR* Disable XULRunner by adding the option {{-Dorg.jboss.tools.vpe.loadxulrunner=false}} to the {{eclipse.ini}} (or {{jbdevstudio.ini}} if you use JBoss Developer Studio)
> If you do not have Intel OpenCL SDK installed but still getting the R6034 error, we will very appreciate if you run Process Explorer as described in [this comment|https://issues.jboss.org/browse/JBIDE-2720?focusedCommentId=12772...] and help us to find conflicting library.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JBIDE-2720) Need 64-bit windows support
by Konstantin Marmalyukov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-2720?page=com.atlassian.jira.plugin... ]
Konstantin Marmalyukov updated JBIDE-2720:
------------------------------------------
Attachment: screenshot-1.png
> Need 64-bit windows support
> ---------------------------
>
> Key: JBIDE-2720
> URL: https://issues.jboss.org/browse/JBIDE-2720
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: visual-page-editor-core
> Affects Versions: 2.1.0.GA, 2.1.1, 2.1.2, 3.0.0.alpha
> Reporter: Samuel Mendenhall
> Assignee: Konstantin Marmalyukov
> Fix For: 4.2.x
>
> Attachments: .mozconfig, buildlog1.log, buildlog1_x86_short.log, buildlog2.log, buildlog2_x86_short.log, buildlog3.log, build_error_when_run_x64.bat.txt, build_log_win_sdk6.log.txt, build_log_win_sdk7.log.txt, c-runtime-error.png, mozconfig1, mozconfig2, screenshot-1.png, vpe-win-jdk64.png
>
>
> If you use a 64-bit JVM, the XULRunner parts of JBoss Tools does not load.
> We should look into providing a xulrunner for Windows 64-bit.
> *Update:*
> In JBoss Tools 4.1.0 and JBoss Developer Studio 7.0.0 XULRunner for 64-bit Windows is provided via experimental update site: http://download.jboss.org/jbosstools/updates/integration/kepler/core/xulr...
> {color:red}*Known problems:*{color}
> * XULRunner for 64-bit Windows is incompatible with Intel OpenCL SDK
> *If you get [R6034 error|https://issues.jboss.org/browse/JBIDE-2720?focusedCommentId=1277169...] you may:*
> * Try to uninstall Intel OpenCL SDK
> * *OR* Disable XULRunner by adding the option {{-Dorg.jboss.tools.vpe.loadxulrunner=false}} to the {{eclipse.ini}} (or {{jbdevstudio.ini}} if you use JBoss Developer Studio)
> If you do not have Intel OpenCL SDK installed but still getting the R6034 error, we will very appreciate if you run Process Explorer as described in [this comment|https://issues.jboss.org/browse/JBIDE-2720?focusedCommentId=12772...] and help us to find conflicting library.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JBIDE-17656) Forge crashed Eclipse
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17656?page=com.atlassian.jira.plugi... ]
Vineet Reynolds edited comment on JBIDE-17656 at 8/27/14 8:00 AM:
------------------------------------------------------------------
Yes, attaching the file. It was in some daemon thread.
However, I can confirm that Forge does invoke {{System.gc}} rather vigorously on Windows. On Antonio's script alone, it exceeds 200. This is specifcally due to invocations in the {{org.jboss.forge.addon.resource.AbstractFileResource.setContents(InputStream)}} method.
Scaffolding being File I/O intensive would explain why the GC activity peaks during scaffolding.
was (Author: vineet.reynolds):
Yes, attaching the file. It was in some daemon thread.
However, I can confirm that Forge does invoke {{System.gc}} rather vigorously on Windows. On Antonio's script alone, it exceeds 200.
Scaffolding being File I/O intensive would explain why the GC activity peaks during scaffolding.
> Forge crashed Eclipse
> ---------------------
>
> Key: JBIDE-17656
> URL: https://issues.jboss.org/browse/JBIDE-17656
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: forge
> Affects Versions: 4.2.0.Beta3
> Environment: Windows 7 64bits, JDK 8.0.0, JBDS 8.0.0.Beta2
> Reporter: Fred Bricon
> Assignee: Vineet Reynolds
> Fix For: 4.2.0.CR1
>
> Attachments: generate.fsh, hs_err_pid4536.log, hs_err_pid5320.log, hs_err_pid640.log, JVM-GCactivity-heap.png, JVM-GCactivity-Linux.png, JVM-GCactivity.png
>
>
> I tried to reproduce the steps from JBIDE-17655 a 2nd time, Eclipse crashed while forge was scaffolding
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JBIDE-2720) Need 64-bit windows support
by Mikhail Kalkov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-2720?page=com.atlassian.jira.plugin... ]
Mikhail Kalkov commented on JBIDE-2720:
---------------------------------------
Ok, thanks. I'll try to use the HTML Preview view in the coming days and see how it works.
Btw, I've checked the MSVCR version used by javaw.exe in my case and it apparently loads the one at jdk1.7.0_67\jre\bin\msvcr100.dll. Furthermore, I have both Intel iCLS Client (both x86 and x64) and Intel Management Engine Components (both x86 and x64) in the PATH, but neither of them contain a private MSVCR copy. I haven't analyzed Intel OpenCL SDK because I don't have it installed. On the other hand, Firefox 31 and MS Office 15 seem to come with private copies of msvcr100.dll, but they are not in PATH. Finally, there is a copy of this library in C:\Windows\System32\msvcr100.dll, but somehow JRE picks up an own copy. So, could it be that this problem is specific to JRE version and is fixed in recent releases?
> Need 64-bit windows support
> ---------------------------
>
> Key: JBIDE-2720
> URL: https://issues.jboss.org/browse/JBIDE-2720
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: visual-page-editor-core
> Affects Versions: 2.1.0.GA, 2.1.1, 2.1.2, 3.0.0.alpha
> Reporter: Samuel Mendenhall
> Assignee: Konstantin Marmalyukov
> Fix For: 4.2.x
>
> Attachments: .mozconfig, buildlog1.log, buildlog1_x86_short.log, buildlog2.log, buildlog2_x86_short.log, buildlog3.log, build_error_when_run_x64.bat.txt, build_log_win_sdk6.log.txt, build_log_win_sdk7.log.txt, c-runtime-error.png, mozconfig1, mozconfig2, vpe-win-jdk64.png
>
>
> If you use a 64-bit JVM, the XULRunner parts of JBoss Tools does not load.
> We should look into providing a xulrunner for Windows 64-bit.
> *Update:*
> In JBoss Tools 4.1.0 and JBoss Developer Studio 7.0.0 XULRunner for 64-bit Windows is provided via experimental update site: http://download.jboss.org/jbosstools/updates/integration/kepler/core/xulr...
> {color:red}*Known problems:*{color}
> * XULRunner for 64-bit Windows is incompatible with Intel OpenCL SDK
> *If you get [R6034 error|https://issues.jboss.org/browse/JBIDE-2720?focusedCommentId=1277169...] you may:*
> * Try to uninstall Intel OpenCL SDK
> * *OR* Disable XULRunner by adding the option {{-Dorg.jboss.tools.vpe.loadxulrunner=false}} to the {{eclipse.ini}} (or {{jbdevstudio.ini}} if you use JBoss Developer Studio)
> If you do not have Intel OpenCL SDK installed but still getting the R6034 error, we will very appreciate if you run Process Explorer as described in [this comment|https://issues.jboss.org/browse/JBIDE-2720?focusedCommentId=12772...] and help us to find conflicting library.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months