[JBoss JIRA] (JBIDE-19340) Batch editor does not draw tree properly
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19340?page=com.atlassian.jira.plugi... ]
Alexey Kazakov commented on JBIDE-19340:
----------------------------------------
[~ljelinko] just keep all needed tests cases description in the one JIRA then. IMO it's better than keep so many issues open wich coused by the same problem - JBIDE-19270.
> Batch editor does not draw tree properly
> ----------------------------------------
>
> Key: JBIDE-19340
> URL: https://issues.jboss.org/browse/JBIDE-19340
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: batch, upstream
> Affects Versions: 4.3.0.Alpha1
> Reporter: Lucia Jelinkova
> Assignee: Viacheslav Kabanovich
> Fix For: 4.3.0.Alpha2
>
>
> Sometimes the tree in batch editor is not properly drawn or it disappears completely if you right-click some tree item.
> You can see in at the end of the screencast in the JBIDE-19339 issue.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JBDS-3322) JSR-356: Websockets. Content-assist for annotations
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3322?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov commented on JBDS-3322:
--------------------------------------
We need to investigate it and see what we could (if any) deliver in JBDS 9. I planned to take a look at it as soon as we code freeze JBDS 8.1.0.Beta1.
> JSR-356: Websockets. Content-assist for annotations
> ---------------------------------------------------
>
> Key: JBDS-3322
> URL: https://issues.jboss.org/browse/JBDS-3322
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: requirements, webservices
> Reporter: Alexey Kazakov
> Assignee: Alexey Kazakov
> Labels: websockets
> Fix For: 9.0.x
>
>
> As a Java EE developer, I wish to take advantage of the new Websockets capability.
> Content-assist for annotations such as @ServerEndpoint, @OnMessage.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JBIDE-14642) How to automate process of bumping version for changed modules/submodules for every release
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14642?page=com.atlassian.jira.plugi... ]
Denis Golovin edited comment on JBIDE-14642 at 2/23/15 1:59 PM:
----------------------------------------------------------------
I'll leave it open for now, because It is not exactly what was requested in this issue:
1. Have a dedicated build for version verification
2. Document the how to use tool like this
It is good to have it but sometimes it makes problems like:
1. impossible to verify that unchanged components are compilable in new stream without upversioning. Is there any option do disable this verification?
2. Extra downloading for verification for every build even if version was updated in the beginning of next development stream and no checks are needed anymore.
was (Author: dgolovin):
I'll leave it open for now, because It is not exactly what was requested in this issue:
1. Have a dedicated build for version verification
2. Document the how to use tool like this
It is good to have it but sometimes it makes problems like:
1. impossible to verify that unchanged components are compilable in new stream without upversioning. Is there any option do disable this verification?
2. Extra downloading for verification for every build even if version was updated in the beginning of next development stream and no check are needed anymore.
> How to automate process of bumping version for changed modules/submodules for every release
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-14642
> URL: https://issues.jboss.org/browse/JBIDE-14642
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.1.0.Beta1
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Priority: Optional
> Labels: versioning
> Fix For: 4.3.x
>
>
> The versions of plugins are constantly discovered to not be uptodated when they should and things like Usage and others where it is critical are not getting bumped.
> We need two things:
> A) detect when versions are not bumped properly - we got parts of this in various places, but they are not run nor documented regularly (having a green build verifying versions are not conflicting would be a Good Thing)
> B) document/automate a process which every affected lead can follow to make this happen and if not See #A
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JBIDE-14642) How to automate process of bumping version for changed modules/submodules for every release
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14642?page=com.atlassian.jira.plugi... ]
Denis Golovin commented on JBIDE-14642:
---------------------------------------
I'll leave it open for now, because It is not exactly what was requested in this issue:
1. Have a dedicated build for version verification
2. Document the how to use tool like this
It is good to have it but sometimes it makes problems like:
1. impossible to verify that unchanged components are compilable in new stream without upversioning. Is there any option do disable this verification?
2. Extra downloading for verification for every build even if version was updated in the beginning of next development stream and no check are needed anymore.
> How to automate process of bumping version for changed modules/submodules for every release
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-14642
> URL: https://issues.jboss.org/browse/JBIDE-14642
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.1.0.Beta1
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Priority: Optional
> Labels: versioning
> Fix For: 4.3.x
>
>
> The versions of plugins are constantly discovered to not be uptodated when they should and things like Usage and others where it is critical are not getting bumped.
> We need two things:
> A) detect when versions are not bumped properly - we got parts of this in various places, but they are not run nor documented regularly (having a green build verifying versions are not conflicting would be a Good Thing)
> B) document/automate a process which every affected lead can follow to make this happen and if not See #A
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JBDS-3271) Cordova App Splash Screen Support
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/JBDS-3271?page=com.atlassian.jira.plugin.... ]
Burr Sutter commented on JBDS-3271:
-----------------------------------
OK, if we are both keying off CLI-compatibility, this should mean that we would not "break" the FH build service. For instance, if our config.xml includes the additional app splash screen reference, if that project is uploaded/git push'd into FH land, it should still build without error, but just ignore that particular piece of configuration, is that correct?
if so, let's follow your original approach of being in-line with the CLI.
> Cordova App Splash Screen Support
> ---------------------------------
>
> Key: JBDS-3271
> URL: https://issues.jboss.org/browse/JBDS-3271
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: aerogear-hybrid, requirements
> Reporter: Burr Sutter
> Assignee: Gorkem Ercan
> Fix For: 9.0.0.CR1
>
>
> As a HTML5+Cordova mobile app developer, I need to change the splash screen associated with the application launch.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JBIDE-13835) Improve publish script (split? Move to maven?)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13835?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13835:
------------------------------------
Yes, but *installable* source bundles in the update site are NOT what JBDS Productization requires, as far as I understand. We need a dump of raw sources, from which a product could be rebuilt.
> Improve publish script (split? Move to maven?)
> ----------------------------------------------
>
> Key: JBIDE-13835
> URL: https://issues.jboss.org/browse/JBIDE-13835
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Fix For: 4.3.x
>
>
> Publish script deals with a lot of different and not-always-related things. It makes it difficult to maintain it. We should think about some improvements such as
> * different conventions from different stream
> * components vs aggregate
> * devstudio vs jbosstools.
> Or,
> * Make publishing part of a "mvn deploy" step.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JBIDE-18852) No warning about missing invocation handler for interface
by Rastislav Wagner (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18852?page=com.atlassian.jira.plugi... ]
Rastislav Wagner commented on JBIDE-18852:
------------------------------------------
I just checked this in Alpha1 and the issue resolved. Its a dup of JBIDE-18345
> No warning about missing invocation handler for interface
> ---------------------------------------------------------
>
> Key: JBIDE-18852
> URL: https://issues.jboss.org/browse/JBIDE-18852
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi-extensions
> Affects Versions: 4.2.1.CR1
> Reporter: Rastislav Wagner
> Assignee: Viacheslav Kabanovich
> Fix For: 4.3.0.Alpha2
>
>
> 1. Create CDI 1.1 project and add deltaspike libs
> 2. create partial bean binding
> {code}
> @PartialBeanBinding
> @Target(ElementType.TYPE)
> @Retention(RetentionPolicy.RUNTIME)
> public @interface ExamplePartialBeanBinding {
> }
> {code}
> 3.create interface
> {code}
> import javax.enterprise.context.ApplicationScoped;
> @ApplicationScoped
> @ExamplePartialBeanBinding
> public interface Interf {
> String sayHello(String hello);
> }
> {code}
> FAIL: There's no warning saying that class should have an invocation handler
> 4. create abstract class
> {code}
> import javax.enterprise.context.ApplicationScoped;
> @ApplicationScoped
> @ExamplePartialBeanBinding
> public abstract class Abs {
> public abstract String sayHello(String hello);
> public String otherHey (String hello) {
> return "Other: " + hello;
> }
> }
> {code}
> ASSERT: warning about missing invocation handler is displayed for abstract class
> 5. Check interface class again -> no warning, edit file & save -> warning is displayed
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JBIDE-13835) Improve publish script (split? Move to maven?)
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13835?page=com.atlassian.jira.plugi... ]
Denis Golovin commented on JBIDE-13835:
---------------------------------------
We do have sources for individual components in nightly p2repo's and in aggregated jbt repository.
> Improve publish script (split? Move to maven?)
> ----------------------------------------------
>
> Key: JBIDE-13835
> URL: https://issues.jboss.org/browse/JBIDE-13835
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Fix For: 4.3.x
>
>
> Publish script deals with a lot of different and not-always-related things. It makes it difficult to maintain it. We should think about some improvements such as
> * different conventions from different stream
> * components vs aggregate
> * devstudio vs jbosstools.
> Or,
> * Make publishing part of a "mvn deploy" step.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JBIDE-18345) PartialBeanBinding validation in annotated mode
by Rastislav Wagner (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18345?page=com.atlassian.jira.plugi... ]
Rastislav Wagner closed JBIDE-18345.
------------------------------------
verified in JBDS 9.0.0.Alpha1-v20150216-1042-B11
> PartialBeanBinding validation in annotated mode
> -----------------------------------------------
>
> Key: JBIDE-18345
> URL: https://issues.jboss.org/browse/JBIDE-18345
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: cdi-extensions
> Affects Versions: 4.2.0.CR1
> Reporter: Rastislav Wagner
> Assignee: Viacheslav Kabanovich
> Fix For: 4.3.0.Alpha1
>
>
> Create CDI 1.1 project with deltaspike libs (and PartialBean module).
> Create Binding Annotation
> {code}
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Retention;
> import java.lang.annotation.RetentionPolicy;
> import java.lang.annotation.Target;
> import org.apache.deltaspike.partialbean.api.PartialBeanBinding;
> @PartialBeanBinding
> @Target(ElementType.TYPE)
> @Retention(RetentionPolicy.RUNTIME)
> public @interface ExamplePartialBeanBinding {
> }
> {code}
> Create Partial Bean interface annotated with Binding Annotation
> {code}
> import javax.enterprise.context.ApplicationScoped;
> @ApplicationScoped
> @ExamplePartialBeanBinding
> public interface ExamplePartialBeanInterface {
> String sayHello(String hello);
> }
> {code}
> In this case a warning saying "Partial bean %className% should have an invocation handler for binding annotation %annotationName%" should be displayed. However because bean-discovery-mode is set to annotated and our Binding Annotation doesn't specify scope (we dont create Binding Annotations with scope right ?) no warning is displayed. So we need to change bean-discovery-mode or add scope to our Binding Annotation. It would be nice to have the warning displayed even with "default" settings. WDYT ?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month