[JBoss JIRA] (JBIDE-13297) Prevent from associating xml files to Android xml editor
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13297?page=com.atlassian.jira.plugi... ]
Alexey Kazakov commented on JBIDE-13297:
----------------------------------------
>> 1. Propose a patch and push to fix it in ADT
But it seems that there is no good solution to open ADT editor by default for relevant xml files.
> Prevent from associating xml files to Android xml editor
> --------------------------------------------------------
>
> Key: JBIDE-13297
> URL: https://issues.jboss.org/browse/JBIDE-13297
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: upstream
> Affects Versions: 4.0.0.Final
> Reporter: Stefan Bunciak
> Assignee: Viacheslav Kabanovich
> Fix For: 4.1.2.CR1, 4.2.0.Alpha1
>
>
> After installing the Android Development Tools into JBDS/JBT all xml files gets associated to Android Common Xml Editor, even pom.xml files which we used to open with the Maven POM Editor. This issue was discussed with Burr Sutter on Face2Face that it should be fixed.
--
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, 2 months
[JBoss JIRA] (JBIDE-16407) Decouple openshift from legacy astools code
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16407?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-16407:
-------------------------------------
The commit can wait until progress on the astools branch is determined, if you'd feel more comfortable.
Openshift needs to decide *how* they want to accomplish those goals. If they want to buy into the concept of subsystems and profiles for their server, then they would need to rewrite their server adapter to work with the new API anyway. Or, if they just want to handle it all themselves, roll their own mini-solution, they can do that too.
But, if the ASTools branch is accepted into master, (or even if it's not, honestly) I don't think its smart for openshift to be building out new infrastructure and behavior based on an old api that is hard to follow, not unified in any real way, and a mish-mash of random crap.
So in that regard, I would suggest they either role their own solution, or use the new API, but I would not advise them to build such new infrastructure on an old broken api that can't be changed or enhanced or flexible in any way to accomodate their needs. It is horrendously tied into each other and nearly impossible to decouple. One look at the existing openshift code immediately shows that it was trying to fit a square peg into a round ASTools solution. The old ASTools api was not designed for openshift to be able to use it.
The new one is.
So again, I would advise OS to either roll their own or use the new subsystems / profiles stuff, but I think it would bad for them to continue using the old api (even if we don't merge the astools branch into master).
So, in short, I don't think they'd need to roll it back. But the fact is they do need to design a solution, and the question is whether it'd be their own creation or based on the new astools api. I would honestly suggest they begin looking into the new API to see if it suits their needs and give feedback.
... But I think I'm generally in charge of the os server code anyway ;)
Can we get links to those jiras? It'd help me list out the use cases and see any obvious issues or missing functionality with my newer API.
> Decouple openshift from legacy astools code
> -------------------------------------------
>
> Key: JBIDE-16407
> URL: https://issues.jboss.org/browse/JBIDE-16407
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: openshift
> Affects Versions: 4.2.0.Alpha1
> Reporter: Rob Stryker
> Assignee: Rob Stryker
>
> With coming changes to astools, openshift depends on classes that will most likely be deprecated and removed.
> Even if its not, openshift is currently using an astools framework that is really geared for servers that can change behavior heavily based on various settings. It's not quite appropriate for openshift which has only one core behavior in terms of publishing 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, 2 months
[JBoss JIRA] (JBIDE-16264) @PathParam with hyphen in value shows as JAX-RS error
by Brian Fitzpatrick (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16264?page=com.atlassian.jira.plugi... ]
Brian Fitzpatrick updated JBIDE-16264:
--------------------------------------
Assignee: Xavier Coulon
> @PathParam with hyphen in value shows as JAX-RS error
> -----------------------------------------------------
>
> Key: JBIDE-16264
> URL: https://issues.jboss.org/browse/JBIDE-16264
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.1.1.CR1
> Reporter: Jim Boettcher
> Assignee: Xavier Coulon
> Priority: Minor
>
> if I have a method like:
> @GET
> @Path("/rule/{rule-file-name}")
> public byte[] getRuleSet(@PathParam("rule-file-name") String ruleSetName)
> I get the error:
> @PathParam value 'rule-file-name' does not match any @Path annotation template parameters of the java method and the enclosing java type.
> If I remove the hyphens from "rule-file-name" the error goes away.
> However the hyphen should be allowed.
--
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, 2 months
[JBoss JIRA] (JBIDE-16328) Buglets in JaxrsResourceMethodValidatorDelegate.validatePublicModifierOnJavaMethod()
by Brian Fitzpatrick (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16328?page=com.atlassian.jira.plugi... ]
Brian Fitzpatrick updated JBIDE-16328:
--------------------------------------
Assignee: Xavier Coulon
> Buglets in JaxrsResourceMethodValidatorDelegate.validatePublicModifierOnJavaMethod()
> ------------------------------------------------------------------------------------
>
> Key: JBIDE-16328
> URL: https://issues.jboss.org/browse/JBIDE-16328
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.1.1.Final
> Environment: Eclipse 4.3.1 EE bundle + JBoss Tools 4.1.1
> Reporter: Thomas Maslen
> Assignee: Xavier Coulon
> Priority: Minor
>
> JAX-RS resource methods are often declared in classes, but it is also valid to declare them in interfaces. Methods in classes have to be explicitly declared public (and that's what this validator method checks for -- good), but methods in Java interfaces are implicitly public; explicitly writing "public" just adds clutter.
> The JAX-RS validator does discover resource methods in interfaces and validates them (good), but if the methods aren't explicitly labelled public then a couple of minor bugs surface in this validator method:
> (1) It adds a RESOURCE_METHOD_NO_PUBLIC_MODIFIER problem marker, and
> (2) The Description that's displayed for the marker is "The method '{0}' should be public.", i.e. the "{0}" isn't replaced with a method name
> (Yes, I can certainly dodge this by changing the "Missing 'public' method modifier" preference from Warning to Ignore, but I'm definitely a fan of having the validators there to save me from myself).
--
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, 2 months
[JBoss JIRA] (JBDS-2492) JBDS Icon problems in Gnome 3.6 Application Switcher
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-2492?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-2492:
-------------------------------------
Image is not affected by this PR, so it is probably gonna be the same. I'll open separate issue for image to push this PR to active branches.
> JBDS Icon problems in Gnome 3.6 Application Switcher
> ----------------------------------------------------
>
> Key: JBDS-2492
> URL: https://issues.jboss.org/browse/JBDS-2492
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: ui/branding
> Affects Versions: 6.0.1.GA
> Environment: Ubuntu Linux x86_64
> Gnome 3.6.0
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Priority: Minor
> Fix For: 7.1.1.CR1, 8.0.0.Alpha2
>
> Attachments: app-switcher.png, appnamefixed.png, appnamexfce.png
>
>
> Problems are:
> # Icon Resolution is to low
> # No application name under icon
> !app-switcher.png!
--
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, 2 months
[JBoss JIRA] (JBIDE-13297) Prevent from associating xml files to Android xml editor
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13297?page=com.atlassian.jira.plugi... ]
Denis Golovin commented on JBIDE-13297:
---------------------------------------
So far our options to deal with this are:
1. Propose a patch and push to fix it in ADT
2. Feature patch available from central
3. OSGi hook
4. Use workaround through "Open With ..."
> Prevent from associating xml files to Android xml editor
> --------------------------------------------------------
>
> Key: JBIDE-13297
> URL: https://issues.jboss.org/browse/JBIDE-13297
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: upstream
> Affects Versions: 4.0.0.Final
> Reporter: Stefan Bunciak
> Assignee: Viacheslav Kabanovich
> Fix For: 4.1.2.CR1, 4.2.0.Alpha1
>
>
> After installing the Android Development Tools into JBDS/JBT all xml files gets associated to Android Common Xml Editor, even pom.xml files which we used to open with the Maven POM Editor. This issue was discussed with Burr Sutter on Face2Face that it should be fixed.
--
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, 2 months
[JBoss JIRA] (JBIDE-13297) Prevent from associating xml files to Android xml editor
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13297?page=com.atlassian.jira.plugi... ]
Denis Golovin commented on JBIDE-13297:
---------------------------------------
One more option is use OSGi hook to override default value to false, but this way from our experience full of hidden problems.
> Prevent from associating xml files to Android xml editor
> --------------------------------------------------------
>
> Key: JBIDE-13297
> URL: https://issues.jboss.org/browse/JBIDE-13297
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: upstream
> Affects Versions: 4.0.0.Final
> Reporter: Stefan Bunciak
> Assignee: Viacheslav Kabanovich
> Fix For: 4.1.2.CR1, 4.2.0.Alpha1
>
>
> After installing the Android Development Tools into JBDS/JBT all xml files gets associated to Android Common Xml Editor, even pom.xml files which we used to open with the Maven POM Editor. This issue was discussed with Burr Sutter on Face2Face that it should be fixed.
--
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, 2 months
[JBoss JIRA] (JBIDE-13297) Prevent from associating xml files to Android xml editor
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13297?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich edited comment on JBIDE-13297 at 1/30/14 3:08 PM:
------------------------------------------------------------------------
There should be no default editor associated with extension 'xml'. For instance, if user selects XML Editor in File Associations as default, all xml files in Eclipse will be opened with it by default, so that other editors can only be selected through 'Open With...'. User will have to remove/add again *.xml in File Associations to return to normal work.
We could remove ADT's editor from the list of default editors File Associations, but we should leave it empty. And that will not help, because then the editor registry will find ADT's editor as default by its declaration in plugin.xml.
was (Author: scabanovich):
There should be no default editor associated with extension 'xml'. For instance, if user select XML Editor in File Associations as default, all xml files in Eclipse will be opened by it by default, so that other editors can only be selected through 'Open With...'. User will have to remove/add again *.xml in File Associations to return to normal work.
We could remove ADT's editor from the list of default editors File Associations, but we should leave it empty. And that will not help, because then the editor registry will find ADT's editor as default by its declaration in plugin.xml.
> Prevent from associating xml files to Android xml editor
> --------------------------------------------------------
>
> Key: JBIDE-13297
> URL: https://issues.jboss.org/browse/JBIDE-13297
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: upstream
> Affects Versions: 4.0.0.Final
> Reporter: Stefan Bunciak
> Assignee: Viacheslav Kabanovich
> Fix For: 4.1.2.CR1, 4.2.0.Alpha1
>
>
> After installing the Android Development Tools into JBDS/JBT all xml files gets associated to Android Common Xml Editor, even pom.xml files which we used to open with the Maven POM Editor. This issue was discussed with Burr Sutter on Face2Face that it should be fixed.
--
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, 2 months