December 2014 - jbosstools-issues

[JBoss JIRA] (JBIDE-18901) git clone + cordova import

by Gorkem Ercan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18901?page=com.atlassian.jira.plugi... ] Gorkem Ercan updated JBIDE-18901: --------------------------------- Summary: git clone + cordova import (was: Import FeedHenry Cordova(full) project to JBDS) > git clone + cordova import > -------------------------- > > Key: JBIDE-18901 > URL: https://issues.jboss.org/browse/JBIDE-18901 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: aerogear-hybrid > Reporter: Burr Sutter > Assignee: Gorkem Ercan > Fix For: 4.2.3.Final, 4.3.0.Beta1 > > > Currently, the git clone wizard does not work with the Cordova project import. The end-user must run the git clone wizard to a point, then cancel out, then start the cordova project import wizard. > In addition, the git clone wizard is fairly "hard to use". > Feature proposal: add git clone support to the Cordova project import - so it can import from file system AND import from a git URL. > Current UI: http://www.screencast.com/t/2bjzPI6EuEgl -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18921) release webtools site for Eclipse 4.3 Mars to so WTP 3.7 discovery upstream can find it

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18921?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-18921: ------------------------------------ So that Eclipse WebTools can point their server adapter discovery wizard at our new URL. Here's the request from last year: https://bugs.eclipse.org/bugs/show_bug.cgi?id=424213 > release webtools site for Eclipse 4.3 Mars to so WTP 3.7 discovery upstream can find it > --------------------------------------------------------------------------------------- > > Key: JBIDE-18921 > URL: https://issues.jboss.org/browse/JBIDE-18921 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server, updatesite, upstream > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > Need a semi-working placeholder (even if it's a weak first alpha or copy of JBT 4.2.0's site) so that WTP can resolve a valid site for server adapters. > Content that needs to be copied is here: > http://download.jboss.org/jbosstools/static/updates/JBossTools-4.2.0.Fina... (or something newer?) > Destination folder (new folder hierarchy as of JBDS-3208 reorg): > http://download.jboss.org/jbosstools/mars/stable/updates/webtools/ > Upstream issue: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=454810 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TOOLSDOC-576) MobileDev How To: Add DYK for LiveReload auto-enabled for BrowserSim

by Konstantin Marmalyukov (JIRA)

[ https://issues.jboss.org/browse/TOOLSDOC-576?page=com.atlassian.jira.plug... ] Konstantin Marmalyukov commented on TOOLSDOC-576: ------------------------------------------------- what does DYK mean? :) Btw I'd rather add info that livereload will not work with java 7 if web engine is javaFx. Why - see [FAQ|http://tools.jboss.org/documentation/faq/browsersim.html#main-features] > MobileDev How To: Add DYK for LiveReload auto-enabled for BrowserSim > -------------------------------------------------------------------- > > Key: TOOLSDOC-576 > URL: https://issues.jboss.org/browse/TOOLSDOC-576 > Project: Documentation for JBoss Tools and Developer Studio > Issue Type: Enhancement > Components: User Guide - Mobile Web Tools > Affects Versions: 4.2.1.Final > Reporter: Michelle Murray > Assignee: Michelle Murray > Fix For: 4.2.1.Final > > > See https://github.com/jbosstools/jbosstools-website/pull/295 > From [~kmarmaliykov] > {quote} > I'd also notice that if you have livereload server started and then open browsersim livereload will be enabled by default(this feature is available from 4.2.1) > {quote} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TOOLSDOC-576) MobileDev How To: Add DYK for LiveReload auto-enabled for BrowserSim

by Michelle Murray (JIRA)

Michelle Murray created TOOLSDOC-576: ---------------------------------------- Summary: MobileDev How To: Add DYK for LiveReload auto-enabled for BrowserSim Key: TOOLSDOC-576 URL: https://issues.jboss.org/browse/TOOLSDOC-576 Project: Documentation for JBoss Tools and Developer Studio Issue Type: Enhancement Components: User Guide - Mobile Web Tools Affects Versions: 4.2.1.Final Reporter: Michelle Murray Assignee: Michelle Murray Fix For: 4.2.1.Final See https://github.com/jbosstools/jbosstools-website/pull/295 >From [~kmarmaliykov] {quote} I'd also notice that if you have livereload server started and then open browsersim livereload will be enabled by default(this feature is available from 4.2.1) {quote} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically

by Darryl Miles (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ] Darryl Miles commented on JBIDE-18862: -------------------------------------- I've never said the problem is easy to solve. :) My own view has always been (since last 7+ years) have a very efficient remotable API. So efficient that is can work in local mode too without any noticeable performance difference. This might mean the AS has code to provide a file/dir manifest of the deployment location, with filenames/fileLength/lastModifiedTimestamp/hashChecksum. The IDE would push delta changes only. The AS would positively acknowledge actions that are going on. The Eclipse IDE would maintain one long running socket connection to the server. You can push file changes down the socket (and have the AS buffer them) even if the AS can not update the files in the deployment area yet because something conflicting is starting/stopping. Since the AS is in control of all file changes to the deployment area itself, it could maintain the current view, transactional updates to that fileset view, and because it was aware of what has changed it can optimize the functions on the AS about what it needs to do to refresh/restart sub-deployments. It also doesn't have to maintain a 1:1 file-system view to logical deployment view, in the case that a file or directory can not be deleted (due to file locking), it could just re-allocate/re-direct the logical deployment view to some temporary location. Even a clean and full publish might still push delta changes, because the AS doesn't have to remove files (it has previously been sent), if it has a hash match for a JAR it has been previous sent it can simply re-use the data. The IDE pushes a complete file-set view to the AS (with filelength/file-content-hashes), the AS comes back with information about which resources it has hits for, providing a unique reference. The IDE can selectively decide which items to push and which items to let the AS resolve from its cache. I've never bought the argument that we must optimize for local, the issue is that remote is too in-efficient to use for local. > when removing a module from AS runtime marker files are not removed automatically > --------------------------------------------------------------------------------- > > Key: JBIDE-18862 > URL: https://issues.jboss.org/browse/JBIDE-18862 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Environment: Windiws7 64bit, JDK 8u25 > Reporter: Darryl Miles > Priority: Minor > Fix For: 4.2.2.Final, 4.3.0.Alpha1 > > > module removal does not delete the various marker files relating to it: > *.undeployed > *.dodeploy > The same should be true when ADDING a module, it should clean out any marker files. > Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written. > Write out the*.ear file. > Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18919) Weak performance on Software/Update tab features loading

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18919?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-18919: --------------------------------------------- this kinda of heavy calculation shouldn't happen in normal operations - is this new ? > Weak performance on Software/Update tab features loading > -------------------------------------------------------- > > Key: JBIDE-18919 > URL: https://issues.jboss.org/browse/JBIDE-18919 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: central > Affects Versions: 4.2.1.CR1 > Reporter: Pavol Srna > Assignee: Mickael Istria > Fix For: 4.2.1.Final > > > It takes about ~1 minute to load content into Software/Update tab in central. > Some of my colleagues noticed this too. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18711) Cordova plugin addition and removal fails when config.xml is in a linked folder

by Vlado Pakan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18711?page=com.atlassian.jira.plugi... ] Vlado Pakan commented on JBIDE-18711: ------------------------------------- [~tkriz] I did not please create one I somehow missed this I apologize. > Cordova plugin addition and removal fails when config.xml is in a linked folder > ------------------------------------------------------------------------------- > > Key: JBIDE-18711 > URL: https://issues.jboss.org/browse/JBIDE-18711 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid > Affects Versions: 4.2.0.Final > Environment: Oracle JDK 1.8.0_05, Mac OS X Mavericks > Reporter: Vineet Reynolds > Assignee: Gorkem Ercan > Fix For: 4.2.2.Final, 4.3.0.Alpha1 > > > When config.xml is present in an Eclipse Linked folder (not in a symbolic link), then attempting to add or remove plugins (and possibly other operations on config.xml) fails with a spurious NullPointerException (without a stacktrace). > This pretty much means that the Hybrid Mobile application project with a linked folder for 'www' is in a read-only state for plugin addition/removal. If any plugin should be added or removed, the linked folder must be dropped, converted to an ordinary folder (or symbolic link), and then re-created after modifications. > To verify > 1. create a new project > 2. copy www folder to an alternate location > 3. remove www folder > 4.add www folder from alternate location as a linked folder (New Folder > Advanced> Link to alternate location) > 5. add cordova plugins to the project. [Check they are added] -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-18862: ------------------------------------- > Also, I'm not sure that ever deleting an .isdeploying marker is ever appropriate. This is referring to the case of a running server. Obviously a stopped server is more likely to be a stale .isdeploying marker. The problem is, the same logic is used against remote servers as for local, and the 'externally managed' checkbox means we never *really* know if the remote server is up or down. I'm trying to fix that in another bug, but when 'externally managed' is checked we don't *really* know. We don't necessarily have a reference to a remote process if it was started externally, and so we can't check if the remote process exists or what. > when removing a module from AS runtime marker files are not removed automatically > --------------------------------------------------------------------------------- > > Key: JBIDE-18862 > URL: https://issues.jboss.org/browse/JBIDE-18862 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Environment: Windiws7 64bit, JDK 8u25 > Reporter: Darryl Miles > Priority: Minor > Fix For: 4.2.2.Final, 4.3.0.Alpha1 > > > module removal does not delete the various marker files relating to it: > *.undeployed > *.dodeploy > The same should be true when ADDING a module, it should clean out any marker files. > Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written. > Write out the*.ear file. > Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18711) Cordova plugin addition and removal fails when config.xml is in a linked folder

by Tadeas Kriz (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18711?page=com.atlassian.jira.plugi... ] Tadeas Kriz commented on JBIDE-18711: ------------------------------------- [~vpakan] did you open a separate issue for this? I've hit the same thing in WFK 2.7.0 ER2 yesterday, so I'm asking if I should go on and create a new ticket of if you already did. Thanks. > Cordova plugin addition and removal fails when config.xml is in a linked folder > ------------------------------------------------------------------------------- > > Key: JBIDE-18711 > URL: https://issues.jboss.org/browse/JBIDE-18711 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid > Affects Versions: 4.2.0.Final > Environment: Oracle JDK 1.8.0_05, Mac OS X Mavericks > Reporter: Vineet Reynolds > Assignee: Gorkem Ercan > Fix For: 4.2.2.Final, 4.3.0.Alpha1 > > > When config.xml is present in an Eclipse Linked folder (not in a symbolic link), then attempting to add or remove plugins (and possibly other operations on config.xml) fails with a spurious NullPointerException (without a stacktrace). > This pretty much means that the Hybrid Mobile application project with a linked folder for 'www' is in a read-only state for plugin addition/removal. If any plugin should be added or removed, the linked folder must be dropped, converted to an ordinary folder (or symbolic link), and then re-created after modifications. > To verify > 1. create a new project > 2. copy www folder to an alternate location > 3. remove www folder > 4.add www folder from alternate location as a linked folder (New Folder > Advanced> Link to alternate location) > 5. add cordova plugins to the project. [Check they are added] -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-18862: ------------------------------------- My race condition had to do if we put a .dodeploy marker, and the server has not yet switched it to a .deploying marker. In this case, the filesystem scanner has not yet begun to pick up the deployment. If I then delete the .dodeploy marker, to make some incremental changes, and don't add a .dodeploy marker back, then the server *never* picks up the deployment. 1) We copy a full publish directory structure to a clean deployments folder 2) we add a .dodeploy marker 3) an incremental publish to the same module is invoked in eclipse 4) the server has not yet picked up the deployment is present. The .dodeploy marker is still there 5) We (eclipse) delete the .dodeploy marker 6) We add whatever incremental file changes need to be made 7) We do not add another .dodeploy marker, since we are doing an incremental publish and are trying to minimize redeployments 8) The server never picks up the deployment at all. It did not get to see a .dodeploy marker ever. We removed it during the incremental publish before the server saw it, and we did not add one back. This is the race condition I'm referring to. To do this properly, I would need to verify the incremental publish is not pre-empting a full publish / .dodeploy marker, and then re-add the .dodeploy marker after the incrementa publish... but this would complicate things quite a bit. Furthermore, if there was a stale .dodeploy there that wasn't supposed to be there, I'd probably assume I was pre-empting an actual full deployment, and re-add the marker when I wasn't supposed to. Also, I'm not sure that ever deleting an .isdeploying marker is *ever* appropriate. I'm not clued into the details on the server side, but, this seems like it'd be interrupting a deployment or canceling a deployment that was in progress. If it's an incremental publish that's deleting the .isdeploying (and thus canceling the server's deployment), I would need to know to re-add the .dodeploy marker yet again, even though I'm doing an incremental publish and wouldn't typically add a .dodeploy marker in that case. This problem isn't as simple as it seems. > when removing a module from AS runtime marker files are not removed automatically > --------------------------------------------------------------------------------- > > Key: JBIDE-18862 > URL: https://issues.jboss.org/browse/JBIDE-18862 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Environment: Windiws7 64bit, JDK 8u25 > Reporter: Darryl Miles > Priority: Minor > Fix For: 4.2.2.Final, 4.3.0.Alpha1 > > > module removal does not delete the various marker files relating to it: > *.undeployed > *.dodeploy > The same should be true when ADDING a module, it should clean out any marker files. > Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written. > Write out the*.ear file. > Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues December 2014