[JBoss JIRA] (JBDS-2949) Require Java 7 for the IDE
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBDS-2949:
-----------------------------------------
Summary: Require Java 7 for the IDE
Key: JBDS-2949
URL: https://issues.jboss.org/browse/JBDS-2949
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Max Rydahl Andersen
Run the IDE with Java 7 (Java 6 no longer supported) (Users applications and servers can still use older and newer JDK’s like Java 1.4,5,6, 8 etc.) P1
Java 6 is no longer supported by Oracle and by requiring Java 7 we can use better native IO and JavaFX (only on oracle)
Forge already requires Java 7.
Concerns: If we do not run with Java 6 we cannot support Xulrunner based VPE on OSX.
--
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, 1 month
[JBoss JIRA] (JBDS-2949) Require Java 7 for the IDE
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-2949?page=com.atlassian.jira.plugin.... ]
CDW Engine updated JBDS-2949:
-----------------------------
CDW pm_ack: ?
CDW release: ?
> Require Java 7 for the IDE
> --------------------------
>
> Key: JBDS-2949
> URL: https://issues.jboss.org/browse/JBDS-2949
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Max Rydahl Andersen
>
> Run the IDE with Java 7 (Java 6 no longer supported) (Users applications and servers can still use older and newer JDK’s like Java 1.4,5,6, 8 etc.) P1
> Java 6 is no longer supported by Oracle and by requiring Java 7 we can use better native IO and JavaFX (only on oracle)
> Forge already requires Java 7.
> Concerns: If we do not run with Java 6 we cannot support Xulrunner based VPE on OSX.
--
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, 1 month
[JBoss JIRA] (JBDS-2840) Java 8
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2840?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen updated JBDS-2840:
--------------------------------------
Priority: Critical (was: Major)
> Java 8
> ------
>
> Key: JBDS-2840
> URL: https://issues.jboss.org/browse/JBDS-2840
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: requirements, upstream
> Reporter: Burr Sutter
> Priority: Critical
>
> Support for Java 8
> - The IDE running with Java 8 on all OS platforms
> - The capabilities in Eclipse Luna for code editing/support
> - EAP 6.3 with Java 8 (start, stop,deploy, debug, etc)
--
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, 1 month
[JBoss JIRA] (JBIDE-16651) Remove hard-coded enterprise dependency resolution for upcoming archetypes embedding the RedHat Maven repo
by Rafael Benevides (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16651?page=com.atlassian.jira.plugi... ]
Rafael Benevides commented on JBIDE-16651:
------------------------------------------
PR for jdf-stacks merged.
> Remove hard-coded enterprise dependency resolution for upcoming archetypes embedding the RedHat Maven repo
> ----------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-16651
> URL: https://issues.jboss.org/browse/JBIDE-16651
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: maven, project-examples
> Affects Versions: 4.1.1.Final
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Fix For: 4.1.2.CR1
>
>
> In JBoss Central, when an Enterprise runtime is selected for any given Archetype, we check if the Red Hat Enterprise repository is available by trying to resolve a redhat version of org.jboss.spec:jboss-javaee-web-6.0. Then, if some essential dependencies are defined in stacks.yaml, we also try to resolve these. If the dependencies can't be resolved, a warning message appears with a link allowing users to add the RH repo to their Maven settings.xml
> Upcoming archetypes will have the Red Hat repository already added to the generated pom.xml, so adding it to settings.xml becomes unnecessary. However, we'd get false positive warning by trying to resolve org.jboss.spec:jboss-javaee-web-6.0 from the settings.xml *before* generating the archetype.
> Our goal is to remove the hardcoded check from MavenArtifactHelper and, when necessary, declare org.jboss.spec:jboss-javaee-web-6.0 as an essential dependency in stacks.yaml for *old* archetypes that do not add the RH repo to the gen'd pom.xml
--
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, 1 month
[JBoss JIRA] (JBDS-2948) Improve Performance of small and large projects
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2948?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen updated JBDS-2948:
--------------------------------------
Summary: Improve Performance of small and large projects (was: Importing small or large projects with many dependencies should not be slow)
> Improve Performance of small and large projects
> -----------------------------------------------
>
> Key: JBDS-2948
> URL: https://issues.jboss.org/browse/JBDS-2948
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Epic
> Security Level: Public(Everyone can see)
> Reporter: Max Rydahl Andersen
>
> Users have had noticable issues when importing projects having many schemas, many annotations and dependencies in past. Our and WTP validators seem to be causing issues - some are actual performance issues and others seem to be more perceived than actual issues.
> Unfortunately perceived issues for the user feels just as slow as real issues.
> Suggestion:
> Look in jira for performance issues and add "performance" label to them
> Allocate dev to use profiler to spot hotspots and get these findings reported/documented and then triage based on these findings
> Work with QE to setup performance measurements for end user common operations related to these issues (example: import project, run validation etc.) for small (quickstarts), medium (ticketmonster) and large (wildfly) projects and publish these numbers over time and keep track if getting better/worse.
> Setup goals to reach for these performance measurements.
> Don’t add new features that make performance worse. For example don’t introduce one more slow validation feature to the validator which already has performance issues until those issues are solved.
--
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, 1 month
[JBoss JIRA] (JBIDE-16651) Remove hard-coded enterprise dependency resolution for upcoming archetypes embedding the RedHat Maven repo
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16651?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-16651:
-------------------------------------
PR for jbosstools-central applied. Now waiting for [~rafabene] to apply the stacks one.
> Remove hard-coded enterprise dependency resolution for upcoming archetypes embedding the RedHat Maven repo
> ----------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-16651
> URL: https://issues.jboss.org/browse/JBIDE-16651
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: maven, project-examples
> Affects Versions: 4.1.1.Final
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Fix For: 4.1.2.CR1
>
>
> In JBoss Central, when an Enterprise runtime is selected for any given Archetype, we check if the Red Hat Enterprise repository is available by trying to resolve a redhat version of org.jboss.spec:jboss-javaee-web-6.0. Then, if some essential dependencies are defined in stacks.yaml, we also try to resolve these. If the dependencies can't be resolved, a warning message appears with a link allowing users to add the RH repo to their Maven settings.xml
> Upcoming archetypes will have the Red Hat repository already added to the generated pom.xml, so adding it to settings.xml becomes unnecessary. However, we'd get false positive warning by trying to resolve org.jboss.spec:jboss-javaee-web-6.0 from the settings.xml *before* generating the archetype.
> Our goal is to remove the hardcoded check from MavenArtifactHelper and, when necessary, declare org.jboss.spec:jboss-javaee-web-6.0 as an essential dependency in stacks.yaml for *old* archetypes that do not add the RH repo to the gen'd pom.xml
--
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, 1 month
[JBoss JIRA] (JBDS-2948) Importing small or large projects with many dependencies should not be slow
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2948?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen updated JBDS-2948:
--------------------------------------
Description:
Users have had noticable issues when importing projects having many schemas, many annotations and dependencies in past. Our and WTP validators seem to be causing issues - some are actual performance issues and others seem to be more perceived than actual issues.
Unfortunately perceived issues for the user feels just as slow as real issues.
Suggestion:
Look in jira for performance issues and add "performance" label to them
Allocate dev to use profiler to spot hotspots and get these findings reported/documented and then triage based on these findings
Work with QE to setup performance measurements for end user common operations related to these issues (example: import project, run validation etc.) for small (quickstarts), medium (ticketmonster) and large (wildfly) projects and publish these numbers over time and keep track if getting better/worse.
Setup goals to reach for these performance measurements.
Don’t add new features that make performance worse. For example don’t introduce one more slow validation feature to the validator which already has performance issues until those issues are solved.
> Importing small or large projects with many dependencies should not be slow
> ---------------------------------------------------------------------------
>
> Key: JBDS-2948
> URL: https://issues.jboss.org/browse/JBDS-2948
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Epic
> Security Level: Public(Everyone can see)
> Reporter: Max Rydahl Andersen
>
> Users have had noticable issues when importing projects having many schemas, many annotations and dependencies in past. Our and WTP validators seem to be causing issues - some are actual performance issues and others seem to be more perceived than actual issues.
> Unfortunately perceived issues for the user feels just as slow as real issues.
> Suggestion:
> Look in jira for performance issues and add "performance" label to them
> Allocate dev to use profiler to spot hotspots and get these findings reported/documented and then triage based on these findings
> Work with QE to setup performance measurements for end user common operations related to these issues (example: import project, run validation etc.) for small (quickstarts), medium (ticketmonster) and large (wildfly) projects and publish these numbers over time and keep track if getting better/worse.
> Setup goals to reach for these performance measurements.
> Don’t add new features that make performance worse. For example don’t introduce one more slow validation feature to the validator which already has performance issues until those issues are solved.
--
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, 1 month