[JBoss JIRA] (JBIDE-12108) BrowserSim is not visible in Quick Access by default when installed individually
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-12108?page=com.atlassian.jira.plugi... ]
Ilya Buziuk commented on JBIDE-12108:
-------------------------------------
[~maxandersen], PR was sent - https://github.com/jbosstools/jbosstools-browsersim/pull/64
> BrowserSim is not visible in Quick Access by default when installed individually
> --------------------------------------------------------------------------------
>
> Key: JBIDE-12108
> URL: https://issues.jboss.org/browse/JBIDE-12108
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: browsersim
> Affects Versions: 3.3.0.CR1
> Environment: JBT 3.3.0.CR1b, L64, Ubuntu 12.04
> Reporter: Jiri Peterka
> Assignee: Ilya Buziuk
> Fix For: 4.3.0.Beta1
>
> Attachments: browsersim-enabled.png, customize-perspective.png, enable-browsersim.png, mobile-browser.bmp
>
>
> Unable to access BrowserSIM when installed as single feature from JBT CR1. Additional steps are required. This is confusing for a users. BrowserSIM should be accessible and visible after installation if possible.
> *These additional steps are:*
> # Right click on the Eclipse toolbar→Customize Perspective...:
> !customize-perspective.png!
> # Go to the Command Group Availability tab and select BrowserSim command group:
> !enable-browsersim.png!
> # BrowserSim icon will appear on the toolbar:
> !browsersim-enabled.png!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (JBIDE-19369) Disposer method doesnt detect Producer field
by Rastislav Wagner (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19369?page=com.atlassian.jira.plugi... ]
Rastislav Wagner closed JBIDE-19369.
------------------------------------
verified in JBDS 9.0.0.Alpha2-v20150420-1747-B24
> Disposer method doesnt detect Producer field
> --------------------------------------------
>
> Key: JBIDE-19369
> URL: https://issues.jboss.org/browse/JBIDE-19369
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Affects Versions: 4.3.0.Alpha1
> Reporter: Rastislav Wagner
> Assignee: Viacheslav Kabanovich
> Fix For: 4.3.0.Alpha2
>
>
> This applies for CDI 1.1 and 1.2 which allows Disposer method to accept Producer field.
> {code}
> public class B1 {
>
> @Produces EntityManager em;
>
> public void test(@Disposes EntityManager em){
> //do smt
> }
> {code}
> This code results in error "There is no producer method declared by the (same) bean class that is assignable to the disposed parameter of a disposer method [JSR-346 §3.5.3]"
> CDI 1.1 and 1.2 allows also producer filed (see section 3.5)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (JBIDE-18772) Include publish.sh in parent pom as versioned maven dependency
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18772?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-18772:
------------------------------------
build-sites and product both use the parent pom, because they inherit a ton of variables from there, including target platform definitions and URLs for upstream projects.
So... you're wrong there. (But you're right about targetplatforms-matrix - it doesn't use the parent pom.)
But as long as this new system employs a profile to fire rsync using default params, I'm *not -1* on using this new mojo approach.
We'll just need to encode all the stuff I have in the Jenkins configs for aggregates, target platforms, discovery, browsersim-standalone, and product builds into <ugly><xml><blocks> instead of `simple shell`, but hey, that's the price of portability. :D
> Include publish.sh in parent pom as versioned maven dependency
> --------------------------------------------------------------
>
> Key: JBIDE-18772
> URL: https://issues.jboss.org/browse/JBIDE-18772
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Priority: Critical
> Fix For: 4.3.0.Beta1
>
>
> instead of relying to publish.sh being on master, we should use a versioned publish.sh (or maybe even mojo) that the build then uses.
> suggestion:
> publish.sh (or mojo) gets released to our maven repo, use it in the pom.xml to perform publishing.
> What this helps with is:
> a) can do changes to publish mechanism without affecting every past builds.
> b) more movable build system
> c) isolated testing possible
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (JBIDE-19687) Web Service wizard buttons act strangely if an error occurs creating CXF service
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19687?page=com.atlassian.jira.plugi... ]
Xavier Coulon reassigned JBIDE-19687:
-------------------------------------
Assignee: Brian Fitzpatrick
> Web Service wizard buttons act strangely if an error occurs creating CXF service
> --------------------------------------------------------------------------------
>
> Key: JBIDE-19687
> URL: https://issues.jboss.org/browse/JBIDE-19687
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.3.0.Alpha2
> Environment: Fedora 20 x64, openjdk 1.7.0_75
> Reporter: Jan Richter
> Assignee: Brian Fitzpatrick
>
> Trying to create a bottom up Apache CXF web service. If after the "Apache CXF Wbe Service Java2WS Configuration" step an error occurs, the "back" and "next" buttons stop behaving in the expected fashion.
> So far I've found these cases:
> - The back button will loop through the last 3 pages of the wizard, while pressing "next" on any of these pages will return you to the first page.
> - You can return with the back button, but pressing next will open an error dialog with the same message as the original error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ]
Xavier Coulon commented on JBIDE-19605:
---------------------------------------
[~bfitzpat],
can you take a look at this issue ? It's related to the org.jboss.tools.ws.ui bundle.
thanks !
> Avoid need for multiple javax.servlet
> -------------------------------------
>
> Key: JBIDE-19605
> URL: https://issues.jboss.org/browse/JBIDE-19605
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: target-platform, webservices
> Affects Versions: 4.3.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Brian Fitzpatrick
>
> We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1.
> {code}
> On 04/15/2015 11:56 PM, Nick Boldt wrote:
> > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and
> > 3.1.0 in JBDS.
> > More importantly... SHOULD we be including both? Or can we just include
> > 3.1.0 and drop 3.0.0?
> I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both).
> So I've tried the ultimate test:
> $ cd jbdevstudio-9.0.0.Alpha2/studio
> $ rm plugins/javax.servlet_3.0.0*
> $ ./jbdevstudio
> And saw
> !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967]
> Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)"
> at org.eclipse.osgi.container.Module.start(Module.java:434)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ]
Xavier Coulon reassigned JBIDE-19605:
-------------------------------------
Assignee: Xavier Coulon
> Avoid need for multiple javax.servlet
> -------------------------------------
>
> Key: JBIDE-19605
> URL: https://issues.jboss.org/browse/JBIDE-19605
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: target-platform, webservices
> Affects Versions: 4.3.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Xavier Coulon
>
> We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1.
> {code}
> On 04/15/2015 11:56 PM, Nick Boldt wrote:
> > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and
> > 3.1.0 in JBDS.
> > More importantly... SHOULD we be including both? Or can we just include
> > 3.1.0 and drop 3.0.0?
> I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both).
> So I've tried the ultimate test:
> $ cd jbdevstudio-9.0.0.Alpha2/studio
> $ rm plugins/javax.servlet_3.0.0*
> $ ./jbdevstudio
> And saw
> !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967]
> Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)"
> at org.eclipse.osgi.container.Module.start(Module.java:434)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ]
Xavier Coulon reassigned JBIDE-19605:
-------------------------------------
Assignee: Brian Fitzpatrick (was: Xavier Coulon)
> Avoid need for multiple javax.servlet
> -------------------------------------
>
> Key: JBIDE-19605
> URL: https://issues.jboss.org/browse/JBIDE-19605
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: target-platform, webservices
> Affects Versions: 4.3.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Brian Fitzpatrick
>
> We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1.
> {code}
> On 04/15/2015 11:56 PM, Nick Boldt wrote:
> > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and
> > 3.1.0 in JBDS.
> > More importantly... SHOULD we be including both? Or can we just include
> > 3.1.0 and drop 3.0.0?
> I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both).
> So I've tried the ultimate test:
> $ cd jbdevstudio-9.0.0.Alpha2/studio
> $ rm plugins/javax.servlet_3.0.0*
> $ ./jbdevstudio
> And saw
> !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967]
> Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)"
> at org.eclipse.osgi.container.Module.start(Module.java:434)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years