[JBoss JIRA] (JBIDE-16330) Deployment to Android emulator ignores saved run configuration
by Vineet Reynolds (JIRA)
Vineet Reynolds created JBIDE-16330:
---------------------------------------
Summary: Deployment to Android emulator ignores saved run configuration
Key: JBIDE-16330
URL: https://issues.jboss.org/browse/JBIDE-16330
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: aerogear-hybrid
Affects Versions: 4.1.1.Final
Reporter: Vineet Reynolds
The deployment to an emulator is always performed on a currently running AVD even if the runtime config for the project specifies a different AVD.
Ignore/reject if this is by design. But from the point of view of the user, it would be better to ensure consistency - when a user wants to run his project on a specific AVD, he needs to create a runtime config, but the moment a different AVD is running, this config is ignored.
--
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, 3 months
[JBoss JIRA] (JBIDE-12971) Add mockito to the TP
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-12971?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-12971:
----------------------------------------
There are indeed good things about fragments that make them sometimes better than bundles for test (for example when it comes to package visibility). So I'm not trying to convince you to move from fragment to bundle, I was just giving food for thoughts.
I generally don't like forked stuff because they introduce technical debt (difficulty to move to newer versions, unexpected different behaviour...) , and as a maintainer of the JBoss Tools target platform I'd rather see a "vanilla" distribution in JBT TP.
It seems to me that the elegant way to get it working is to use a fragment, and I believe it wouldn't be difficult for you to adopt this standard approach and get rid of some forked code to maintain.
If you could give a link to the implementation of IMockitoConfiguration you'd like to use, I could try to make a pull request setting it up in a fragment and configuring tycho-surefire-plugin to use this during tests.
> Add mockito to the TP
> ---------------------
>
> Key: JBIDE-12971
> URL: https://issues.jboss.org/browse/JBIDE-12971
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.0.0.Beta1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.2.0.Alpha2
>
>
> It would be great if we could use mockito (http://code.google.com/p/mockito/) in our tests. We would have to add it to our target platform (TP) for our plugins to use it.
--
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, 3 months
[JBoss JIRA] (JBIDE-12971) Add mockito to the TP
by Paul Richardson (JIRA)
[ https://issues.jboss.org/browse/JBIDE-12971?page=com.atlassian.jira.plugi... ]
Paul Richardson commented on JBIDE-12971:
-----------------------------------------
[~mickael_istria]
Respectfully, I disagree with your assertion that test bundles as fragments is not a good idea. They have served me well on both this and my previous projects.
Either way, with 36 test fragments in the Designer codebase, I cannot justify the effort of modifying them just to workaround a shortcoming in the Mockito library.
Given the forked Mockito library is the same as the version its forked from for 95% of test cases, is it really of concern to have it removed from Locus?
> Add mockito to the TP
> ---------------------
>
> Key: JBIDE-12971
> URL: https://issues.jboss.org/browse/JBIDE-12971
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.0.0.Beta1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.2.0.Alpha2
>
>
> It would be great if we could use mockito (http://code.google.com/p/mockito/) in our tests. We would have to add it to our target platform (TP) for our plugins to use it.
--
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, 3 months
[JBoss JIRA] (JBIDE-16321) Smart DnD from jQuery Mobile Palette
by Daniel Azarov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16321?page=com.atlassian.jira.plugi... ]
Daniel Azarov commented on JBIDE-16321:
---------------------------------------
There are two ways to insert items from palette to the editor:
1. Drag&Drop item from palette to the editor.
2. Set text cursor in the editor then click on palette item.
For first way we should enable/disable drag&drop. For second way we should enable/disable palette items.
> Smart DnD from jQuery Mobile Palette
> ------------------------------------
>
> Key: JBIDE-16321
> URL: https://issues.jboss.org/browse/JBIDE-16321
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: jsp/jsf/xml/html source editing
> Reporter: Alexey Kazakov
> Assignee: Daniel Azarov
> Labels: new_and_noteworthy
> Fix For: 4.2.0.Alpha2
>
>
> When adding a widget via the jQuery Mobile Palette, we should inject the HTML in a proper place of the page, not just wherever the cursor happens to be. For example a page may be injected only between pages.
--
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, 3 months
[JBoss JIRA] (JBIDE-12971) Add mockito to the TP
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-12971?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-12971:
----------------------------------------
Assuming you go for a fragment contributing to Mockito bundles:
You'd have tweak the test executor (tycho-surefire-plugin in pom.xml, Launch Configuration in IDE) to make sure the fragment is added to the test runtime. If it's there, then Mockito would be able to see the configuration.
Your tests don't need to be fragments (I actually believe tests as fragments are not a good idea and are worse than tests as regular bundle).
Assuming we can add a "registered" buddy policy to Orbit's Mockito:
You'll need a single bundle contributing to this buddy policy (the one holding the configuration) and your test bunldes or fragments could add a dependency on it to make sure it's part of the test runtime so Mockite could find it.
> Add mockito to the TP
> ---------------------
>
> Key: JBIDE-12971
> URL: https://issues.jboss.org/browse/JBIDE-12971
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.0.0.Beta1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.2.0.Alpha2
>
>
> It would be great if we could use mockito (http://code.google.com/p/mockito/) in our tests. We would have to add it to our target platform (TP) for our plugins to use it.
--
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, 3 months
[JBoss JIRA] (JBIDE-12971) Add mockito to the TP
by Paul Richardson (JIRA)
[ https://issues.jboss.org/browse/JBIDE-12971?page=com.atlassian.jira.plugi... ]
Paul Richardson commented on JBIDE-12971:
-----------------------------------------
[~mickael_istria]
It all hinges on use fragments as tests.
I did investigate Eclipse's buddy policy right at the start. I cannot remember precisely the reason for it not working but I think it relates to the following:
* The mockito bundle would need to declare a buddy policy of some kind in its manifest, eg. registered;
* EVERY test fragment would have to include the modified configuration class
* I think it is also impossible to declare a buddy policy on the fragment (I could be wrong!). If this is the case then the host plugin would require the buddy policy and then that plugin is declaring a buddy policy with a test framework, architecturally wrong and (again my memory is faillible!) with fail at runtime with classpath issues if mockito is not present.
As for using fragments
Fragments cannot depend on fragments. I was asked this on the on the mockito [list|https://groups.google.com/d/msg/mockito/eLE186uE0uc/o3_OIwpUoP8J] as well.
> Add mockito to the TP
> ---------------------
>
> Key: JBIDE-12971
> URL: https://issues.jboss.org/browse/JBIDE-12971
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.0.0.Beta1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.2.0.Alpha2
>
>
> It would be great if we could use mockito (http://code.google.com/p/mockito/) in our tests. We would have to add it to our target platform (TP) for our plugins to use it.
--
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, 3 months
[JBoss JIRA] (JBIDE-16327) JaxrsFacetedProjectListener doesn't support RESTEasy 3?
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16327?page=com.atlassian.jira.plugi... ]
Xavier Coulon commented on JBIDE-16327:
---------------------------------------
Thomas,
Thanks for reporting this issue ;-)
The JAX-RS tooling does not support JAX-RS 2.0 at the moment. You may use the support for JAX-RS 1.1 on your project (with the workaround you described), but some validators may return false-positive errors in some cases. If you want to get rid of wrong validation messages, you can configure the JAX-RS validators at the project level or at the workbench level (set the validator level to 'ignore' where needed).
I opened https://issues.jboss.org/browse/JBIDE-16329 to track the work on supporting JAX-RS 2.0 in the next version of JBoss Tools.
> JaxrsFacetedProjectListener doesn't support RESTEasy 3?
> -------------------------------------------------------
>
> Key: JBIDE-16327
> URL: https://issues.jboss.org/browse/JBIDE-16327
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.1.1.Final
> Environment: Eclipse EE bundle 4.3.1 + JBoss Tools 4.1.1
> Reporter: Thomas Maslen
> Assignee: Xavier Coulon
> Priority: Minor
> Fix For: 4.1.2.Final, 4.2.0.Alpha2
>
>
> More generally: JaxrsFacetedProjectListener supports exactly JAX-RS 1.1 but not 2.0?
> (Perhaps that is intentional, and that's why various text labels in the public UI explicitly say "JAX-RS 1.1" rather than just "JAX-RS"?)
--
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, 3 months