July 2014 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-18002) Changes to files in nested utility project need not always restart module

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18002?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-18002: -------------------------------- Attachment: JBIDE-18002.png New proposed UI > Changes to files in nested utility project need not always restart module > ------------------------------------------------------------------------- > > Key: JBIDE-18002 > URL: https://issues.jboss.org/browse/JBIDE-18002 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: server > Affects Versions: 4.2.0.Beta3 > Reporter: Rob Stryker > Labels: affects_documentation > Fix For: 4.2.0.CR1 > > Attachments: JBIDE-18002.png > > > Changes to a .class file inside a nested utility project currently marks the module as requiring a restart, because the application server won't pick up those changes without a restart. > When running in debug mode, though, the debugger will use the new classes as changed in the workspace, so a restart of a module is slow and costly. > The fix (for now) would be to only restart the web module if the publish is a full publish, or, if the nested archive's deployment name matches the strings in the server editor's restart-module regex clause. > Example project replicating the bug can be found at https://github.com/maxandersen/JBIDE-17724 > Unzip the attached project structure (stripped down from an existing project) > Run 'mvn clean install eclipse:clean eclipse:eclipse' at the root > Import existing projects into eclipse luna with JBoss Tools > Deploy to a "JBoss Enterprise Application Platform 5.x" runtime > Make a change to MyController.java inside the project-war webapp => the change is hot deployed > Make a change to MySecondController.java inside the project-module dependency => the full WAR is undeployed then redeployed -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17990) Organize imports does not work for Maven dependencies

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17990?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-17990: ------------------------------- Assignee: Fred Bricon > Organize imports does not work for Maven dependencies > ----------------------------------------------------- > > Key: JBIDE-17990 > URL: https://issues.jboss.org/browse/JBIDE-17990 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: maven > Affects Versions: 4.2.0.Beta3 > Environment: Oracle JDK 1.8.0_05, Eclipse Luna > Reporter: Harald Wellmann > Assignee: Fred Bricon > Fix For: 4.2.0.CR1 > > > After upgrading from 4.2.0.Beta2 to Beta3 to test the fix for JBIDE-17724, Organize Imports is broken in my workspace. More precisely, I'm referring to the capability of finding the package a class lives in and generating the {{import}} directive with the FQCN. > The corresponding Quick Fix is also broken. > It only works for class names from sources in the workspace, it no longer works for class names from a Maven dependency in the local repository. > This is even worse than JBIDE-17724, I'll have to revert to Beta2. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17990) Organize imports does not work for Maven dependencies

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17990?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-17990: ------------------------------- Component/s: maven > Organize imports does not work for Maven dependencies > ----------------------------------------------------- > > Key: JBIDE-17990 > URL: https://issues.jboss.org/browse/JBIDE-17990 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: maven > Affects Versions: 4.2.0.Beta3 > Environment: Oracle JDK 1.8.0_05, Eclipse Luna > Reporter: Harald Wellmann > > After upgrading from 4.2.0.Beta2 to Beta3 to test the fix for JBIDE-17724, Organize Imports is broken in my workspace. More precisely, I'm referring to the capability of finding the package a class lives in and generating the {{import}} directive with the FQCN. > The corresponding Quick Fix is also broken. > It only works for class names from sources in the workspace, it no longer works for class names from a Maven dependency in the local repository. > This is even worse than JBIDE-17724, I'll have to revert to Beta2. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17990) Organize imports does not work for Maven dependencies

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17990?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-17990: ------------------------------- Fix Version/s: 4.2.0.CR1 > Organize imports does not work for Maven dependencies > ----------------------------------------------------- > > Key: JBIDE-17990 > URL: https://issues.jboss.org/browse/JBIDE-17990 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: maven > Affects Versions: 4.2.0.Beta3 > Environment: Oracle JDK 1.8.0_05, Eclipse Luna > Reporter: Harald Wellmann > Fix For: 4.2.0.CR1 > > > After upgrading from 4.2.0.Beta2 to Beta3 to test the fix for JBIDE-17724, Organize Imports is broken in my workspace. More precisely, I'm referring to the capability of finding the package a class lives in and generating the {{import}} directive with the FQCN. > The corresponding Quick Fix is also broken. > It only works for class names from sources in the workspace, it no longer works for class names from a Maven dependency in the local repository. > This is even worse than JBIDE-17724, I'll have to revert to Beta2. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17944) BrowserSim: Use http: protocol instead of file: for accessing local files

by Konstantin Marmalyukov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17944?page=com.atlassian.jira.plugi... ] Konstantin Marmalyukov updated JBIDE-17944: ------------------------------------------- Fix Version/s: 4.3.0.Alpha1 > BrowserSim: Use http: protocol instead of file: for accessing local files > ------------------------------------------------------------------------- > > Key: JBIDE-17944 > URL: https://issues.jboss.org/browse/JBIDE-17944 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: browsersim > Reporter: Alexey Kazakov > Assignee: Konstantin Marmalyukov > Fix For: 4.3.0.Alpha1 > > > Currently, BrowserSim works through file: protocol but this protocol doesn't work well with paths relative to the webroot (which start with "/"). > So if a local file contains any links to local resources (css, js, ...) via relative paths then these resources are not available in BrowserSim. > For example all official ionic example projects use such paths. It makes "open with BrowserSim" feature useless for those projects. > It would be great if BrowserSim uses http: as our HTML5 preview does. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17934) cordova-3.5.0.jar missing when exporting andriod project

by Konstantin Marmalyukov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17934?page=com.atlassian.jira.plugi... ] Konstantin Marmalyukov updated JBIDE-17934: ------------------------------------------- Assignee: Gorkem Ercan > cordova-3.5.0.jar missing when exporting andriod project > -------------------------------------------------------- > > Key: JBIDE-17934 > URL: https://issues.jboss.org/browse/JBIDE-17934 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid, browsersim > Affects Versions: 4.2.0.Beta2 > Environment: Mac OSx 10.9.4, Eclipse Luna (4.4.0), Jboss Tools for Luna (4.2.0.Beta2), with Jboss Hybrid Mobile Tools + CordovaSim. > Reporter: Asif Kilwani > Assignee: Gorkem Ercan > > When trying to test "run on Andriod device" or export native platform project > Error generating the native android project > /Users/Administrator/.cordova/lib/android/cordova/3.5.0/framework/cordova-3.5.0.jar (No such file or directory) > I deleted framework and downloaded again from properties, but same. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17934) cordova-3.5.0.jar missing when exporting andriod project

by Konstantin Marmalyukov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17934?page=com.atlassian.jira.plugi... ] Konstantin Marmalyukov updated JBIDE-17934: ------------------------------------------- Fix Version/s: 4.2.0.CR1 > cordova-3.5.0.jar missing when exporting andriod project > -------------------------------------------------------- > > Key: JBIDE-17934 > URL: https://issues.jboss.org/browse/JBIDE-17934 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid, browsersim > Affects Versions: 4.2.0.Beta2 > Environment: Mac OSx 10.9.4, Eclipse Luna (4.4.0), Jboss Tools for Luna (4.2.0.Beta2), with Jboss Hybrid Mobile Tools + CordovaSim. > Reporter: Asif Kilwani > Assignee: Gorkem Ercan > Fix For: 4.2.0.CR1 > > > When trying to test "run on Andriod device" or export native platform project > Error generating the native android project > /Users/Administrator/.cordova/lib/android/cordova/3.5.0/framework/cordova-3.5.0.jar (No such file or directory) > I deleted framework and downloaded again from properties, but same. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17724) Changes cause full redeployment of exploded WAR

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17724?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-17724. --------------------------------- Fix Version/s: (was: 4.2.0.CR1) Resolution: Done I've opened https://issues.jboss.org/browse/JBIDE-18002 to track this case. Closing this issue here as resolved in b3, since it was. > Changes cause full redeployment of exploded WAR > ----------------------------------------------- > > Key: JBIDE-17724 > URL: https://issues.jboss.org/browse/JBIDE-17724 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.2.0.Beta2 > Environment: Windows 8.1 x64 > Java 7u51 x64 > Luna x64 > Reporter: Cody Lerum > Assignee: Rob Stryker > Priority: Blocker > Labels: respin-b > Fix For: 4.2.0.Beta3 > > Attachments: JBIDE-17724-JBossEAP5-testcase.tar.bz2, workspace.zip > > > After moving to Luna from Kepler any changes to java or jsf resources are causing a full redeployment of the exploded war to JBoss 7.1.3.Final > This prevents any updating of JSF resources or debugging java code. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18002) Changes to files in nested utility project need not always restart module

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18002?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-18002: -------------------------------- Fix Version/s: 4.2.0.CR1 > Changes to files in nested utility project need not always restart module > ------------------------------------------------------------------------- > > Key: JBIDE-18002 > URL: https://issues.jboss.org/browse/JBIDE-18002 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: server > Affects Versions: 4.2.0.Beta3 > Reporter: Rob Stryker > Labels: affects_documentation > Fix For: 4.2.0.CR1 > > > Changes to a .class file inside a nested utility project currently marks the module as requiring a restart, because the application server won't pick up those changes without a restart. > When running in debug mode, though, the debugger will use the new classes as changed in the workspace, so a restart of a module is slow and costly. > The fix (for now) would be to only restart the web module if the publish is a full publish, or, if the nested archive's deployment name matches the strings in the server editor's restart-module regex clause. > Example project replicating the bug can be found at https://github.com/maxandersen/JBIDE-17724 > Unzip the attached project structure (stripped down from an existing project) > Run 'mvn clean install eclipse:clean eclipse:eclipse' at the root > Import existing projects into eclipse luna with JBoss Tools > Deploy to a "JBoss Enterprise Application Platform 5.x" runtime > Make a change to MyController.java inside the project-war webapp => the change is hot deployed > Make a change to MySecondController.java inside the project-module dependency => the full WAR is undeployed then redeployed -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18002) Changes to files in nested utility project need not always restart module

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18002?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-18002: -------------------------------- Labels: affects_documentation (was: ) > Changes to files in nested utility project need not always restart module > ------------------------------------------------------------------------- > > Key: JBIDE-18002 > URL: https://issues.jboss.org/browse/JBIDE-18002 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: server > Affects Versions: 4.2.0.Beta3 > Reporter: Rob Stryker > Labels: affects_documentation > Fix For: 4.2.0.CR1 > > > Changes to a .class file inside a nested utility project currently marks the module as requiring a restart, because the application server won't pick up those changes without a restart. > When running in debug mode, though, the debugger will use the new classes as changed in the workspace, so a restart of a module is slow and costly. > The fix (for now) would be to only restart the web module if the publish is a full publish, or, if the nested archive's deployment name matches the strings in the server editor's restart-module regex clause. > Example project replicating the bug can be found at https://github.com/maxandersen/JBIDE-17724 > Unzip the attached project structure (stripped down from an existing project) > Run 'mvn clean install eclipse:clean eclipse:eclipse' at the root > Import existing projects into eclipse luna with JBoss Tools > Deploy to a "JBoss Enterprise Application Platform 5.x" runtime > Make a change to MyController.java inside the project-war webapp => the change is hot deployed > Make a change to MySecondController.java inside the project-module dependency => the full WAR is undeployed then redeployed -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 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 July 2014