[JBoss JIRA] (JBIDE-12972) Add FestAssert to the TP
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-12972?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-12972:
----------------------------------------
We don't want to add things that people could use in TP, we really to add things that people want or need to use, so that it's sure they will use them.
So [~mgagyi], do you want or need festassert? Will you use it if we introduce it in TP?
> Add FestAssert to the TP
> ------------------------
>
> Key: JBIDE-12972
> URL: https://issues.jboss.org/browse/JBIDE-12972
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: target-platform
> Affects Versions: 4.0.0.Beta1
> Reporter: Xavier Coulon
> Assignee: Xavier Coulon
> Priority: Minor
> Fix For: 4.2.x
>
>
> It would be great if we could use in our tests. We would have to add it to our target platform (TP) for our plugins to use it.
> Reason: FestAssert provides us with a Fluent API to write test assertions.
> License and owner: Apache License 2.0 / http://code.google.com/p/fest/
> Original repository: (not an Eclipse bundle yet). Source and binaries available on Maven (https://repository.jboss.org/nexus/content/groups/public/org/easytesting/... and https://repository.jboss.org/nexus/content/groups/public/org/easytesting/...)
> JBoss Mirrored repository: http://downloads.jboss.org/jbosstools/updates/requirements/fest-assert ?
> Source: https://github.com/alexruiz/fest-assert-1.x
> Affected projects: LiveReload for now, JAX-RS in the future
> Required in devstudio: No for now (if LiveReload is considered incubation)
> Type of dependency: testing
> List of bundles added/removed: fest-assert, fest-util
> Fest-assert provides a fluent API to perform asertions in JUnit tests. It is also nice to use when the objects to tests are collections.
> To convince you of the interest of fest-assert, here are a few syntax examples:
> - In LiveReload-test plugin:
> {code}
> assertThat(new String(modifiedContent)).doesNotContain(addition + "</body>");
> {code}
> - a more complete example of usage in openShift-java-client (not an Eclipse plugin, though, but it gives an idea of the chained assertions that can be performed)
> {code}
> assertThat(new GearGroupsAssert(gearGroups))
> .assertGroup(0).hasUUID().hasGears()
> .assertGear(0).hasId().hasState();
> {code}
> - in case of assertion failure on such a statement:
> {code}
> Assertions.assertThat(commands).hasSize(2);
> {code}
> the exception message will look like this:
> {code}
> java.lang.AssertionError: expected size:<2> but was:<1> for <['{"command":"reload","path":null,"liveCSS":true}']>
> at org.fest.assertions.Fail.failure(Fail.java:228)
> at org.fest.assertions.Assert.failure(Assert.java:149)
> at org.fest.assertions.GroupAssert.hasSize(GroupAssert.java:89)
> at org.jboss.tools.livereload.internal.service.LiveReloadCommandGeneratorTestCase.shouldGenerateCommandForIndexHtmlFileAfterSingleChange(LiveReloadCommandGeneratorTestCase.java:45)
> at ...
> {code}
> See more examples here: http://code.google.com/p/fest/#Fluent_Assertions
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-19049) Enable JBoss servers to run with java 9
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19049?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-19049:
-------------------------------------
I spent about 2-3 hours trying to get Java9 support enabled in a basic rudimentary way. I managed to get it added to the proper execution environments, but, after that, It failed spectacularly ;)
http://www.jroller.com/andyl/entry/say_hello_to_jep_220
They have now hidden the various jars inside a jimage file, which means large amounts of jdt probably need to be rewritten. I doubt I can substantially help here.
Java platform’s Chief Architect, Mark Reinhold explained that Oracle’s plans to replace JAR files with modules in the JRE and JDK will have an impact on IDEs. “This will affect a small class of applications, mainly IDEs and other kinds of development tools that need to enumerate and inspect the classes stored in a run-time image.”
> Enable JBoss servers to run with java 9
> ---------------------------------------
>
> Key: JBIDE-19049
> URL: https://issues.jboss.org/browse/JBIDE-19049
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.2.2.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Labels: Java9
> Fix For: 4.3.0.Alpha1
>
>
> I briefly tried to use java 9 for our tooling and to run servers.
> I downloaded it from here:
> https://jdk9.java.net/download/
> {code}
> nattura:8.0.2 rasp$ java -version
> java version "1.9.0-ea"
> Java(TM) SE Runtime Environment (build 1.9.0-ea-b45)
> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b45, mixed mode)
> {code}
> I use OS X 10.10 Yosemite.
> There are a couple of problems:
> 1. When I add a WildFly 8.2 server into JBDS 8.0.2, I cannot change the runtime to use java 9 - it seems we restrict that.
> 2. Even if I could, we need to make sure -XX:MaxPermSize is not used in the server launch command. When I tried to run WildFly 8.2 from the terminal, it wouldn't work unless I removed the max perm size argument. Apparently java 9 does not just ignore this parameter (as java 8 did), but it does not allow it at all.
> {code}
> nattura:bin rasp$ ./standalone.sh
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final
> JAVA: /Library/Java/JavaVirtualMachines/jdk1.9.0.jdk/Contents/Home/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> Unrecognized VM option 'MaxPermSize=256m'
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> {code}
> Of course it's questionable if we should allow java 9 for current servers at all as they don't support it officially. But I would say there is no need to restrict it if it works.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBTIS-393) Update BPMN2 to 1.1.2.201502050700
by Paul Leacu (JIRA)
Paul Leacu created JBTIS-393:
--------------------------------
Summary: Update BPMN2 to 1.1.2.201502050700
Key: JBTIS-393
URL: https://issues.jboss.org/browse/JBTIS-393
Project: JBoss Tools Integration Stack
Issue Type: Task
Components: BPMN2
Affects Versions: 4.2.1.CR1, 8.0.1.CR1
Reporter: Paul Leacu
Assignee: Paul Leacu
Fix For: 4.2.1.CR1, 8.0.1.CR1
Mirror in jbosstools and update TP and aggregate composite - BPMN2 Modeler 1.1.2.201502050700.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBDS-3250) Support for OpenShift 3 with Docker and Kubernetes
by Jeff Cantrill (JIRA)
[ https://issues.jboss.org/browse/JBDS-3250?page=com.atlassian.jira.plugin.... ]
Jeff Cantrill updated JBDS-3250:
--------------------------------
Description:
Copied from JBDS-3278:
As an OpenShift v3 end-user, I need to be deploy, undeploy, add, remove, etc. for applications targeting the v3 API.
The UI for OpenShift Explorer will need to be expanded (or replaced) to handle v3's new terminology and architecture.
For June @Burr tells us to implement (Mail "Forget everything you know about OpenShift"):
{quote}
It could be as simple as…somewhere in OpenShift v3 is the git URL to a source repo….
Our Eclipse end-user needs to be able to “browse” for it and select it
git clone it
make changes
git push it back
{quote}
This gives us 3 main use cases (as in mail and chats):
# Import existing OpenShift project (JBDS-3297)
# Push Changes to Existing OpenShift project (JBDS-3298)
# New Project from Template (template should have a default buildconfig, deployconfig and docker image) (JBDS-3306)
{quote}
Use Case #1 assumes a TON about what has happened before me.
- Assumes that OpenShift Enterprise is installed, configured and running happily at an accessible URL
- Assumes end-user is already logged in (there is no auth method at this time)
- Assumes that someone else (not our eclipse end-user) has manually created his/her “project” with an image, a git repo, a deployment config, a build config, defined routes, defined services, etc.
{quote}
We have a more extensive document that outlines the usecases:
https://docs.google.com/a/redhat.com/document/d/1VwYNuKWUzuorU-6GcF420Vl_...
{quote}
These are features/capabilities currently NOT planned for OpenShift v3's Eclipse Tooling:
1) Create SSH Keys
2) Upload SSH Keys
3) Create Domain
4) Add a database, message broker, cache (embeddable cartridge)
5) Show In Web Browser
6) Review Env Vars
7) Edit Env Vars
8) Review Logs
9) Log Streaming
10) SSH in
11) Delete/Destroy
12) Remote Debugging (though that might "just work")
13) Snapshot creation
14) Snapshot restore
15) Port Forwarding
16) Marker Files
17) Node.js
18) PHP
19) Python
20) C++
21) Perl
{quote}
was:
Copied from JBDS-3278:
As an OpenShift v3 end-user, I need to be deploy, undeploy, add, remove, etc. for applications targeting the v3 API.
The UI for OpenShift Explorer will need to be expanded (or replaced) to handle v3's new terminology and architecture.
For June @Burr tells us to implement (Mail "Forget everything you know about OpenShift"):
{quote}
It could be as simple as…somewhere in OpenShift v3 is the git URL to a source repo….
Our Eclipse end-user needs to be able to “browse” for it and select it
git clone it
make changes
git push it back
{quote}
This gives us 3 main use cases (as in mail and chats):
# Import existing OpenShift project (JBDS-3297)
# Push Changes to Existing OpenShift project (JBDS-3298)
# New Project from Template (template should have a default buildconfig, deployconfig and docker image)
{quote}
Use Case #1 assumes a TON about what has happened before me.
- Assumes that OpenShift Enterprise is installed, configured and running happily at an accessible URL
- Assumes end-user is already logged in (there is no auth method at this time)
- Assumes that someone else (not our eclipse end-user) has manually created his/her “project” with an image, a git repo, a deployment config, a build config, defined routes, defined services, etc.
{quote}
We have a more extensive document that outlines the usecases:
https://docs.google.com/a/redhat.com/document/d/1VwYNuKWUzuorU-6GcF420Vl_...
{quote}
These are features/capabilities currently NOT planned for OpenShift v3's Eclipse Tooling:
1) Create SSH Keys
2) Upload SSH Keys
3) Create Domain
4) Add a database, message broker, cache (embeddable cartridge)
5) Show In Web Browser
6) Review Env Vars
7) Edit Env Vars
8) Review Logs
9) Log Streaming
10) SSH in
11) Delete/Destroy
12) Remote Debugging (though that might "just work")
13) Snapshot creation
14) Snapshot restore
15) Port Forwarding
16) Marker Files
17) Node.js
18) PHP
19) Python
20) C++
21) Perl
{quote}
> Support for OpenShift 3 with Docker and Kubernetes
> --------------------------------------------------
>
> Key: JBDS-3250
> URL: https://issues.jboss.org/browse/JBDS-3250
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Epic
> Components: openshift
> Reporter: Max Rydahl Andersen
> Assignee: Andre Dietisheim
> Fix For: 9.0.0.GA
>
>
> Copied from JBDS-3278:
> As an OpenShift v3 end-user, I need to be deploy, undeploy, add, remove, etc. for applications targeting the v3 API.
> The UI for OpenShift Explorer will need to be expanded (or replaced) to handle v3's new terminology and architecture.
> For June @Burr tells us to implement (Mail "Forget everything you know about OpenShift"):
> {quote}
> It could be as simple as…somewhere in OpenShift v3 is the git URL to a source repo….
> Our Eclipse end-user needs to be able to “browse” for it and select it
> git clone it
> make changes
> git push it back
> {quote}
> This gives us 3 main use cases (as in mail and chats):
> # Import existing OpenShift project (JBDS-3297)
> # Push Changes to Existing OpenShift project (JBDS-3298)
> # New Project from Template (template should have a default buildconfig, deployconfig and docker image) (JBDS-3306)
> {quote}
> Use Case #1 assumes a TON about what has happened before me.
> - Assumes that OpenShift Enterprise is installed, configured and running happily at an accessible URL
> - Assumes end-user is already logged in (there is no auth method at this time)
> - Assumes that someone else (not our eclipse end-user) has manually created his/her “project” with an image, a git repo, a deployment config, a build config, defined routes, defined services, etc.
> {quote}
> We have a more extensive document that outlines the usecases:
> https://docs.google.com/a/redhat.com/document/d/1VwYNuKWUzuorU-6GcF420Vl_...
> {quote}
> These are features/capabilities currently NOT planned for OpenShift v3's Eclipse Tooling:
> 1) Create SSH Keys
> 2) Upload SSH Keys
> 3) Create Domain
> 4) Add a database, message broker, cache (embeddable cartridge)
> 5) Show In Web Browser
> 6) Review Env Vars
> 7) Edit Env Vars
> 8) Review Logs
> 9) Log Streaming
> 10) SSH in
> 11) Delete/Destroy
> 12) Remote Debugging (though that might "just work")
> 13) Snapshot creation
> 14) Snapshot restore
> 15) Port Forwarding
> 16) Marker Files
> 17) Node.js
> 18) PHP
> 19) Python
> 20) C++
> 21) Perl
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-12972) Add FestAssert to the TP
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-12972?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-12972 at 2/6/15 11:19 AM:
-------------------------------------------------------------------
[~mgagyi] Matej, is this something that you could use in your test? FestAssert adds nice syntactic sugar to assertions, my guess is that this is something that you could nicely use when doing tests? If yes, then what about trying this out and report to [~nickboldt] in this jira?
was (Author: adietish):
[~mgagyi] Matej, is this something that you could use in your test? FestAssert adds nice syntactic sugar to assertions, my guess is that this is something that you could nicely use when doing tests? If yes, then what about trying this out and report to [~nickboldt]?
> Add FestAssert to the TP
> ------------------------
>
> Key: JBIDE-12972
> URL: https://issues.jboss.org/browse/JBIDE-12972
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: target-platform
> Affects Versions: 4.0.0.Beta1
> Reporter: Xavier Coulon
> Assignee: Xavier Coulon
> Priority: Minor
> Fix For: 4.2.x
>
>
> It would be great if we could use in our tests. We would have to add it to our target platform (TP) for our plugins to use it.
> Reason: FestAssert provides us with a Fluent API to write test assertions.
> License and owner: Apache License 2.0 / http://code.google.com/p/fest/
> Original repository: (not an Eclipse bundle yet). Source and binaries available on Maven (https://repository.jboss.org/nexus/content/groups/public/org/easytesting/... and https://repository.jboss.org/nexus/content/groups/public/org/easytesting/...)
> JBoss Mirrored repository: http://downloads.jboss.org/jbosstools/updates/requirements/fest-assert ?
> Source: https://github.com/alexruiz/fest-assert-1.x
> Affected projects: LiveReload for now, JAX-RS in the future
> Required in devstudio: No for now (if LiveReload is considered incubation)
> Type of dependency: testing
> List of bundles added/removed: fest-assert, fest-util
> Fest-assert provides a fluent API to perform asertions in JUnit tests. It is also nice to use when the objects to tests are collections.
> To convince you of the interest of fest-assert, here are a few syntax examples:
> - In LiveReload-test plugin:
> {code}
> assertThat(new String(modifiedContent)).doesNotContain(addition + "</body>");
> {code}
> - a more complete example of usage in openShift-java-client (not an Eclipse plugin, though, but it gives an idea of the chained assertions that can be performed)
> {code}
> assertThat(new GearGroupsAssert(gearGroups))
> .assertGroup(0).hasUUID().hasGears()
> .assertGear(0).hasId().hasState();
> {code}
> - in case of assertion failure on such a statement:
> {code}
> Assertions.assertThat(commands).hasSize(2);
> {code}
> the exception message will look like this:
> {code}
> java.lang.AssertionError: expected size:<2> but was:<1> for <['{"command":"reload","path":null,"liveCSS":true}']>
> at org.fest.assertions.Fail.failure(Fail.java:228)
> at org.fest.assertions.Assert.failure(Assert.java:149)
> at org.fest.assertions.GroupAssert.hasSize(GroupAssert.java:89)
> at org.jboss.tools.livereload.internal.service.LiveReloadCommandGeneratorTestCase.shouldGenerateCommandForIndexHtmlFileAfterSingleChange(LiveReloadCommandGeneratorTestCase.java:45)
> at ...
> {code}
> See more examples here: http://code.google.com/p/fest/#Fluent_Assertions
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-12972) Add FestAssert to the TP
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-12972?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-12972:
------------------------------------------
[~mgagyi] Matej, is this something that you could use in your test? FestAssert adds nice syntactic sugar to assertions, my guess is that this is something that you could nicely use when doing tests? If yes, then what about trying this out and report to [~nickboldt]?
> Add FestAssert to the TP
> ------------------------
>
> Key: JBIDE-12972
> URL: https://issues.jboss.org/browse/JBIDE-12972
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: target-platform
> Affects Versions: 4.0.0.Beta1
> Reporter: Xavier Coulon
> Assignee: Xavier Coulon
> Priority: Minor
> Fix For: 4.2.x
>
>
> It would be great if we could use in our tests. We would have to add it to our target platform (TP) for our plugins to use it.
> Reason: FestAssert provides us with a Fluent API to write test assertions.
> License and owner: Apache License 2.0 / http://code.google.com/p/fest/
> Original repository: (not an Eclipse bundle yet). Source and binaries available on Maven (https://repository.jboss.org/nexus/content/groups/public/org/easytesting/... and https://repository.jboss.org/nexus/content/groups/public/org/easytesting/...)
> JBoss Mirrored repository: http://downloads.jboss.org/jbosstools/updates/requirements/fest-assert ?
> Source: https://github.com/alexruiz/fest-assert-1.x
> Affected projects: LiveReload for now, JAX-RS in the future
> Required in devstudio: No for now (if LiveReload is considered incubation)
> Type of dependency: testing
> List of bundles added/removed: fest-assert, fest-util
> Fest-assert provides a fluent API to perform asertions in JUnit tests. It is also nice to use when the objects to tests are collections.
> To convince you of the interest of fest-assert, here are a few syntax examples:
> - In LiveReload-test plugin:
> {code}
> assertThat(new String(modifiedContent)).doesNotContain(addition + "</body>");
> {code}
> - a more complete example of usage in openShift-java-client (not an Eclipse plugin, though, but it gives an idea of the chained assertions that can be performed)
> {code}
> assertThat(new GearGroupsAssert(gearGroups))
> .assertGroup(0).hasUUID().hasGears()
> .assertGear(0).hasId().hasState();
> {code}
> - in case of assertion failure on such a statement:
> {code}
> Assertions.assertThat(commands).hasSize(2);
> {code}
> the exception message will look like this:
> {code}
> java.lang.AssertionError: expected size:<2> but was:<1> for <['{"command":"reload","path":null,"liveCSS":true}']>
> at org.fest.assertions.Fail.failure(Fail.java:228)
> at org.fest.assertions.Assert.failure(Assert.java:149)
> at org.fest.assertions.GroupAssert.hasSize(GroupAssert.java:89)
> at org.jboss.tools.livereload.internal.service.LiveReloadCommandGeneratorTestCase.shouldGenerateCommandForIndexHtmlFileAfterSingleChange(LiveReloadCommandGeneratorTestCase.java:45)
> at ...
> {code}
> See more examples here: http://code.google.com/p/fest/#Fluent_Assertions
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBDS-3199) Creating a new HTML5 "from scratch" retains "kitchensink" string in datasources instead of picking up actual project names
by Marek Novotny (JIRA)
[ https://issues.jboss.org/browse/JBDS-3199?page=com.atlassian.jira.plugin.... ]
Marek Novotny commented on JBDS-3199:
-------------------------------------
[~fbricon] new staging repository https://repository.jboss.org/nexus/content/repositories/jboss_releases_st...
> Creating a new HTML5 "from scratch" retains "kitchensink" string in datasources instead of picking up actual project names
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-3199
> URL: https://issues.jboss.org/browse/JBDS-3199
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: central, upstream
> Affects Versions: 8.0.0.GA
> Reporter: Len DiMaggio
> Assignee: Fred Bricon
> Fix For: 8.1.0.GA
>
>
> These "kitchensink" strings are retained:
> grep -ir kitchen *
> main/resources/META-INF/persistence.xml: <jta-data-source>java:jboss/datasources/KitchensinkHTML5MobileQuickstartDS</jta-data-source>
> main/webapp/WEB-INF/kitchensink-quickstart-ds.xml: <datasource jndi-name="java:jboss/datasources/KitchensinkHTML5MobileQuickstartDS"
> main/webapp/WEB-INF/kitchensink-quickstart-ds.xml: pool-name="kitchensink-quickstart" enabled="true"
> test/resources/arquillian-ds.xml: <datasource jndi-name="java:jboss/datasources/KitchensinkHTML5MobileTestDS"
> test/resources/META-INF/test-persistence.xml: <jta-data-source>java:jboss/datasources/KitchensinkHTML5MobileTestDS</jta-data-source>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months