https://sdbg.github.io
Allows you to debug javascript in Eclipse when running your application in
Chrome. Has its limitations and is a work in progress, but it works.
On Tuesday, March 3, 2015 at 1:49:47 AM UTC-7, Liam Stewart wrote:
Debugging javascript is a king size pain in the arse if
What does debugging hibernate/hazelcast have to do anything with debugging
the frontend (GWT) part ?
Yes, debugging in SDM has it's pain points but apart from Dart (which has
its own Chrome version Dartium) every transpiled/compiled languages relies
on source maps and the browser's DevTools,
Just tiny update. Dev mode is still working just fine on Windows with
Chromium 38.0.2125.0 (292384) from Dart 1.8.3 distribution.
On Monday, February 3, 2014 4:01:41 PM UTC-8, Brian Slesinsky wrote:
Mozilla has stopped exporting some C++ symbols that the Firefox plugin
relies on [1].
That is really good news. I haven't tried this yet (need to upgrade IDEA
to 14) but it sounds like one gets most/all the benefits of DevMode
development/debugging yet it's really using SDM. Very impressive.
-Dave
On Thu, Nov 6, 2014 at 6:55 AM, Jens jens.nehlme...@gmail.com wrote:
I'm using
I'm using IntelliJ...I'd like to hear if/how IntelliJ can do this too.
With the released IntelliJ 14 things are a bit easier.
- Create a new GWT run configuration and select User Super Dev Mode and
at the bottom with JavaScript debugger.
- IntelliJ will automatically generate a JavaScript
There's a developer version of Firefox coming out:
https://blog.mozilla.org/blog/2014/11/03/the-first-browser-dedicated-to-developers-is-coming/
Maybe we can ask Mozilla to export the C++ symbols in this developer
version, so the GWT dev plugin can work on this developer version of
Firefox.
Op
IMO, the loss of DevMode is a huge problem for GWT, I understand
SuperDevMode is its replacement but unfortunately that is no where near a
true replacement at least not yet.
It's a bit hard to explain unless you have used both approaches on a large
project but the best way I can think of to
development.
Tim
From: David Hoffer dhoff...@gmail.com
Reply-To: google-web-toolkit@googlegroups.com
Date: Monday, November 3, 2014 at 9:45 AM
To: Google Web Toolkit google-web-toolkit@googlegroups.com
Subject: Re: Development Mode will not be supported in Firefox 27+
IMO, the loss of DevMode
: Development Mode will not be supported in Firefox 27+
IMO, the loss of DevMode is a huge problem for GWT, I understand
SuperDevMode is its replacement but unfortunately that is no where near a
true replacement at least not yet.
It's a bit hard to explain unless you have used both approaches
I definitely use a MVP/C model but not Places. I don't think I should be
tided to one and only one MVP approach.
Places are just for navigation. They have nothing to do with MVP. You can
use them without GWTs Activity class.
However even if I did it's not clear how that would help
I like where you might be going with your last paragraph (the IntelliJ part
)...Other than that there is the experimental Eclipse plugin named SDBG so
you can use your IDE for debugging (but you are still debugging JS!).
IntelliJ can do the same out of the box.
Are you saying that IntelliJ can
If you're using eclipse and chrome, then sdbg is good. It's not perfect,
but it is *much* better than browsing Java source and setting break points
in the browser.
Paul
On 3 Nov 2014 17:49, David Hoffer dhoff...@gmail.com wrote:
I like where you might be going with your last paragraph (the
I'm using IntelliJ...I'd like to hear if/how IntelliJ can do this too.
-Dave
On Mon, Nov 3, 2014 at 11:58 AM, Paul Robinson ukcue...@gmail.com wrote:
If you're using eclipse and chrome, then sdbg is good. It's not perfect,
but it is *much* better than browsing Java source and setting break
I'm using IntelliJ...I'd like to hear if/how IntelliJ can do this too.
https://docs.google.com/document/d/1Sf9lahq0jr0AsxR74ZE-Lntf0y5ZNk0104mhD8ozEuM/edit
Also see the linked issue in the doc.
-- J.
--
You received this message because you are subscribed to the Google Groups
Google
Lost of Development Mode is kind of tombstone for GWT projects in my
company :( Most of Java oriented developers switched to JS frameworks as
they lost their one common language environment argument. JS oriented
developers, well they were always in opposition to slow and clumsy java
With SDM I'm bind to Chrome at least if I want to use source maps ?
Firefox and IE 11 both support source maps as well. Opera should also
support it as it is now based on Chrome. In case source maps is not
supported you still see nearly unoptimized JavaScript that looks very
similar to
Also on Windows it's still possible to use Chrome 36 with devmode. Download
Dart (I'm using 1.5.3 distribution), and use Chromium from there (it's
portable, just copy it to any folder). Also you need
GWT-Developer-Plugin_v1.0.11357.crx of course, see previous post.
On Friday, July 11, 2014
As of now, quite sadly, the GWT plugin is no longer supported in the latest
of versions of Firefox nor Chrome (starting with 35). I've been using GWT
since 2006, and I think it's a sad state of affairs that after so much work
went into GWT's OOPHM (a.k.a Development Mode), we're back to
Hello,
I created this guide (
http://openbpm.wordpress.com/2014/05/31/getting-gwt-plugin-to-work-on-firefox-on-ubuntu-14-04/)
to get multiple versions of firefox running locally in order to be able to
have an older version with GWT working while still use the latest firefox
version for
People, this has been going on since beginning of February with no action
on the part of Mozilla. I have create a new mozilla bug
https://bugzilla.mozilla.org/show_bug.cgi?id=996947 which is about the fact
that GWT developper does not work in Firefox any longer. I have proposed a
workaround
For the direction of an open source project, people who volunteer to do
actual coding are more important than marketing efforts by people who only
want to be users. The intersection of GWT developers and Firefox browser
developers seems to be the empty set, so we have very limited influence.
This
The StackTraceDeobfuscator does not play very well with the Super Dev Mode
code server though.
Reason: StackTraceDeobfuscator needs to have access to the
AABBCD...HF.symbolMap files generated during the last SDM compilation.
However this directory is a moving target in the SDM code server
Ivan, there is an existing bug that's related so I will reply there:
https://code.google.com/p/google-web-toolkit/issues/detail?id=7693
On Thu, Apr 10, 2014 at 7:22 AM, Ivan Markov ivan.mar...@gmail.com wrote:
The StackTraceDeobfuscator does not play very well with the Super Dev Mode
code
IIUC, Chrome will kill DevMode in 35 (current in beta, will reach the
stable channel in
May):
http://blog.chromium.org/2014/04/chrome-35-beta-more-developer-control.html
On Tuesday, February 4, 2014 1:01:41 AM UTC+1, Brian Slesinsky wrote:
Mozilla has stopped exporting some C++ symbols that
The stack-trace in Super Dev Mode is the only major issue that I have. It
would be nice if the UncaughtException in SDM can tell me which line in
java source is causing the problem, instead of giving me those JavaScript
stack-trace messages...
So far I like SDM. My current project is
If you are debugging interactively, using pause on uncaught exceptions
can help. Then you can look at the stack frames in the debugger.
Another workaround is to log stack traces to the server and use
StackTraceDeobfuscator. This will also help you in production:
On Wednesday, April 2, 2014 3:33:43 PM UTC+2, Thomas Broyer wrote:
On Wednesday, April 2, 2014 3:05:22 PM UTC+2, stuckagain wrote:
For me it will depend how well SDM works with IE because that is the main
browser that I need to support. Not all GWT applications are put on the
internet
Regarding sourcemap support for fields/variable names deobfuscation:
1- I found some thoughts on SourceMap.next here:
http://fitzgeraldnick.com/weblog/55/ .
It goes as far as suggesting how conditional breakpoints and eval()
expressed in the source language can work for sourcemap-based
Thank you Brian. I can understand that, as well as I acknowledge the
compensating benefits (which is not an appropriate term to me, as an
extra arm doesn't really compensate loosing a leg).
Hope for GWT that the long term will not be so long, before the the
benefits of I don't have to learn
Hi Thomas,
I just realized that lack of Firefox 27+ support for dev mode recently
(tried it because Chrome's plugin crashed too often) and really think this
is a shoot in the foot for GWT : even if you don't control Mozilla choices
of course, forcing to move to a non-mature SDM is very risky
Do not agree. A lot of people complain about it.
2014-04-02 11:05 GMT+02:00 Jérôme Beau javar...@gmail.com:
Hi Thomas,
I just realized that lack of Firefox 27+ support for dev mode recently
(tried it because Chrome's plugin crashed too often) and really think this
is a shoot in the foot
I just realized that lack of Firefox 27+ support for dev mode recently
(tried it because Chrome's plugin crashed too often) and really think this
is a shoot in the foot for GWT : even if you don't control Mozilla choices
of course, forcing to move to a non-mature SDM is very risky for GWT
For me it will depend how well SDM works with IE because that is the main
browser that I need to support. Not all GWT applications are put on the
internet and in an enterprise environment (more specifically banking) IE is
still king. It will already be a big battle to get them to move to IE9 or
On Wednesday, April 2, 2014 3:05:22 PM UTC+2, stuckagain wrote:
For me it will depend how well SDM works with IE because that is the main
browser that I need to support. Not all GWT applications are put on the
internet and in an enterprise environment (more specifically banking) IE is
Hi Jens,
Just for the record : do you agree that using SDM you cannot inspect Java
values of Java variables in your browser? I agree about the mobile dev,
about knowing the underlying web platform, about everything but... any
debugging session, Java or JS, have to be consistent : if I debug
What exactly do you mean with I cannot inspect Java values of Java
variables with SDM ?
Can you provide an example where you can't inspect a Java value with Chrome
Dev Tools ?
I think Dev Mode will never come back. SDM is here to stay and despite
there is a lot to be desired, with time
A lot of negative feedback (maybe ) has been going for SDM. It seems a
little harsh to my eyes so here is my positive 2 cents.
We are using SDM for a new project which started from zero lines but grows
up pretty fast. We are importing older (even non GWT) modules and 3rd party
projects with a
Am Mittwoch, 2. April 2014 15:57:55 UTC+2 schrieb Jérôme Beau:
Hi Jens,
Just for the record : do you agree that using SDM you cannot inspect Java
values of Java variables in your browser?
Yes thats true. The only Java code you see in the browser is the Java
source file provided via
Hi Ümit,
By I cannot inspect Java values of Java variables I mean that the
source-mapping of the Chrome Dev Tools (which are good for JS) :
- *shows me stuff I'm not interested into *(most of the time) : this is
Window[0], DOM, JS or internal GWT-generated functions or properties
appear, such
It's true these are disadvantages. There are some compensating advantages
that people are pointing out: the code executes faster, it works with
remote websites where latency is higher, it works with mobile phones, and
so on. But there's no question that losing DevMode (other than IE and
Firefox
DevMode is working just fine in Firefox 26 (not 24). And probably will work
till Firefox ESR becomes 27 (it's only 24.4 now). So there is a time frame
for normally working DevMode at least till the end of 2014. I hope SDM will
be much better then.
What I'm concerned about that GWT team don't
On Friday, March 28, 2014 3:58:00 AM UTC+1, James Wendel wrote:
My company got screwed by using GXT2 with gxt-uibinder library that broke
with GWT 2.5 due to compiler changes. We've been stuck on GWT 2.4 for that
reason as we had 100+ .ui.xml files to convert to pure java. We finally did
Can't agree more. Same experience, even contributed to mygwt (previous name
of GXT)...
The nice thing about GWT: making easy/fast small lib's, is also a risk; not
being maintained..
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To
Hello James,
after replace ui.xml by pure javadoes the application compile faster? I
thought ui.xml views increment a lot the compiler time.
Juan
2014-03-27 23:58 GMT-03:00 James Wendel jmwen...@gmail.com:
My company got screwed by using GXT2 with gxt-uibinder library that broke
with GWT
Could you elaborate on how you have your POM setup? I'm trying to make the
switch to SDM but I get errors running run-codeserver. Your setup seems
ideal I'd like to know how you have both of those things configured. Not
sure it matters but I use IntelliJ instead of Eclipse...DM worked great.
My company got screwed by using GXT2 with gxt-uibinder library that broke with
GWT 2.5 due to compiler changes. We've been stuck on GWT 2.4 for that reason as
we had 100+ .ui.xml files to convert to pure java. We finally did the work, but
it was definitely a painful lesson.
--
You received
They have to change, they have to update their tools and move forward, or
quit doing Web dev.
Agree, that's why I spend a lot of grey hairs in using SDM, but it's simple
not there yet saidly... Don't get me wrong, I wish it would as I certainly
see the advantages.
I noticed that it's hard to
On Wednesday, March 5, 2014 9:30:54 AM UTC+1, Ed wrote:
They have to change, they have to update their tools and move forward,
or quit doing Web dev.
Agree, that's why I spend a lot of grey hairs in using SDM, but it's
simple not there yet saidly... Don't get me wrong, I wish it would as
I'm surprised more folks are not excited to jump ship to SuperDevMode.
I'd argue Eclipse DevMode is more pain than it's worth. Certainly, it is
very cool to have your backend and frontend breakpoints set and hit on the
same screen. Yet I've spent a lot of time trying to all of the *Run
I'm surprised more folks are not excited to jump ship to SuperDevMode.
I think because many dev peeps use GWT for enterprise projects.(and
they should of course)...
And for bigger projects, SDM is (still) hard to use (as explained in this
post, and I really tried/used it several times).
And as a corollary, Enterprise culture has a HUGE resistance to change. There
are people out there still using GWT 2.4 (more than 2 years old already!) or
even older versions. The problem is with these people and that culture; most of
the time they chose GWT (and webapps) for bad reasons, and
On Friday, February 28, 2014 10:48:25 PM UTC+1, joerg.h...@googlemail.com
wrote:
Hi Jens,
Maybe you should just give it a serious try ?
I already gave SDM several tries. However it never worked in my case at
all. The problem is that I am not just doing a hello world with GWT but
some
The Chrome Dev Tools support actually most of eclipse's debugger features
like:
- Evaluating deeply into variables
- Conditional breakpoints
- Exception breakpoints (break on uncaught exception and any exception)
- Dynamically evaluating expressions
Missing features are AFAIK Drop to
you can evaluate deeply into variables and objects,
You can do that in Chrome
add conditional breakpoints,
You can do that in Chrome
exception breakpoints,
You can do that in Chrome
dynamically evaluate expressions,
You can do that in Chrome
So the most important
I do not know what Jetty problem Jörg is talking about. I am using GWT
2.6 with FF 26 and I am able to use DevMode.
On Fri, Feb 28, 2014 at 6:21 AM, joerg.hohwil...@googlemail.com
joerg.hohwil...@googlemail.com wrote:
Hi there,
I can understand that it is a hard task to maintain the GWT
On Friday, February 28, 2014 1:59:24 AM UTC+1, Brian Slesinsky wrote:
I'm not sure what the Jetty problems are but they should be fixed. Do we
have a good bug report for them?
There's a strange classloader
issue: https://code.google.com/p/google-web-toolkit/issues/detail?id=8585
And a
Hi Jens,
Maybe you should just give it a serious try ?
I already gave SDM several tries. However it never worked in my case at
all. The problem is that I am not just doing a hello world with GWT but
some rather complex UI framework with some special aspects. I hope that I
do not appear just
Hi there,
I can understand that it is a hard task to maintain the GWT and especially
DevMode with its plugins.
However, the hole thing about GWT is that you can do pure Java and use the
Java tooling.
Developers know how to work with Eclipse. And within the Eclipse debugger
you can evaluate
I'm not sure what the Jetty problems are but they should be fixed. Do we
have a good bug report for them?
(In our setup we see stack traces but Jetty still runs.)
- Brian
On Thu, Feb 27, 2014 at 4:51 PM, joerg.hohwil...@googlemail.com
joerg.hohwil...@googlemail.com wrote:
Hi there,
I can
Would anyone like to follow up the last comment on the bugzilla thread,
where a FF dev claims that:
Most C++ JSAPI usage in extensions can in fact be replaced by a combination of
privileged script and the debugger APIs
I assume we wouldn't be seeing this thread if that was really true as you
I'm not sure there's much to discuss. Firefox 27 is already released, and
we do want to move off of Dev Mode sooner or later for other reasons. I
don't feel comfortable asking them to bring back an API that they never
officially supported anyway and it seems unlikely that they'd agree.
Running
This is a pretty important change for me - looks like it's a downgrade to
FF 26 a workaround is found. I had never heard of Super Dev mode but sounds
like it's still got a fair way to go - and right now I need to focus on ROI
for my work (retooling in the last 90% of a project is not an option
Couldn't agree more... debugging the client-side GWT code in the IDE
debugger (Eclipse in my case) is base of my every day work :(
On Wednesday, February 19, 2014 5:37:01 PM UTC+1, Jeff Evans wrote:
Can someone clarify what is meant by fully functional for Super dev
mode? In my view,
On Thursday, February 20, 2014 9:49:42 AM UTC+1, m...@touk.pl wrote:
Couldn't agree more... debugging the client-side GWT code in the IDE
debugger (Eclipse in my case) is base of my every day work :(
I'm sure the SDBG devs would love to hear your feedback ;-)
https://github.com/sdbg/sdbg
On Thursday, February 20, 2014 11:57:30 AM UTC+1, Thomas Broyer wrote:
I'm sure the SDBG devs would love to hear your feedback ;-)
https://github.com/sdbg/sdbghttps://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fsdbg%2Fsdbgsa=Dsntz=1usg=AFQjCNGpKQKj0nzlbD9UjM3ciaeAEJAb9g
SDBG has a
On Tuesday, February 18, 2014 4:30:50 AM UTC-5, Aleksander Gralak wrote:
That is pretty bad information for all GWT developers.
For now I can stick with FF 24.2, however in the future we need to develop
on the most up to date browsers.
When do you estimate Super Dev Mode will be
Super Dev Mode works and we have many teams that use it. The Chrome
debugger is quite good and I recommend learning it well; anyone working on
web apps will benefit from knowing this tool. For other browsers, adding a
GWT.debugger() call to the Java code and recompiling is an easy way to stop
in
On Wednesday, February 19, 2014 1:03:15 PM UTC-5, Brian Slesinsky wrote:
Super Dev Mode works and we have many teams that use it. The Chrome
debugger is quite good and I recommend learning it well; anyone working on
web apps will benefit from knowing this tool. For other browsers, adding a
The Chrome debugger is quite good and I recommend learning it well;
It depends on your project. I been down this road, tried it several times
with several projects (few months ago last one).
Currently the Super Dev mode is Hello World ready, but not Enterprise
ready
With new projects, I like to
That is pretty bad information for all GWT developers.
For now I can stick with FF 24.2, however in the future we need to develop
on the most up to date browsers.
When do you estimate Super Dev Mode will be production ready? If it is more
then 6 months then we should think of some workaround.
well. no more gwt for me then, until mozilla gives google access again.
downgrading the browser(either by using chrome or an earlier version of
firefox) is not acceptable for me. but i can wait. got lots of non-google
projects to work on.
On Monday, February 3, 2014 8:01:41 PM UTC-4, Brian
Remote debug works great too ;-)
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group,
Remote debug works great too ;-)
Yes, if you have a Mac ;) (I assume you mean Safari remote debugging ?
Else let me know, device independent (iphone, android))
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this
I don't have a Mac. Chrome remote debug works great cross platform (tested with
Chrome for Android, on Linux and Windows; should work w/ Chrome for iOS
AFAICT). Firefox for Android (and FirefoxOS) should too (though I haven't
tested it)
--
You received this message because you are subscribed
Usage example of the chrome debugger (not as part of the Chrome browser):
Wienre: http://people.apache.org/~pmuellr/weinre/docs/latest/
(A very nice tool btw for controlling your DOM on a mobile device)
--
You received this message because you are subscribed to the Google Groups
Google Web
Does the Chrome expose any kind of debugging interface so that any
front-end IDE can use and visualize it ?
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
On Thursday, February 6, 2014 10:03:35 AM UTC+1, Kirill Prazdnikov wrote:
Does the Chrome expose any kind of debugging interface so that any
front-end IDE can use and visualize it ?
https://developers.google.com/chrome-developer-tools/docs/debugger-protocol
--
You received this message
I second the bi-directional breakpoints idea. That's the biggest pain point
for me with SDM. It stinks to track down some code in your IDE then have to
track it down again in your browser to set the break point. If I didn't
have to do that, I wouldn't miss debugging in the IDE much.
On
On Tuesday, February 4, 2014 8:05:16 AM UTC+1, Cristiano wrote:
Hi Brian,
I wonder how does it works the development mode plugin?
Isn't it possible to replace it with something in pure javascript that is
based on Web Sockets?
No, because we need blocking I/O, synchronous communication
No, because we need blocking I/O, synchronous communication with the
DevMode code server.
mmm, good point...
can we just block with a while?
The only solution would be to use the remote debugging protocols so you
can really pause the execution in the browser while you do things in Java.
On Tuesday, February 4, 2014 10:38:34 AM UTC+1, Cristiano wrote:
No, because we need blocking I/O, synchronous communication with the
DevMode code server.
mmm, good point...
can we just block with a while?
Because JS is single-threaded, you'll never know when to break out of the
webworkers?
2014-02-04 Thomas Broyer t.bro...@gmail.com:
On Tuesday, February 4, 2014 10:38:34 AM UTC+1, Cristiano wrote:
No, because we need blocking I/O, synchronous communication with the
DevMode code server.
mmm, good point...
can we just block with a while?
Because JS is
looking at the docs of webworkers and even them don't share any state, so
it won't work it too...
Anyway it would be great to find a workaround that don't require either
Flash or browser plugin or Java Applet...
2014-02-04 Cristiano Costantini cristiano.costant...@gmail.com:
webworkers?
Anything people can look into to improve SDM performance? For example is it
still worth it refactoring generators to be incremental generators or does
the upcoming incremental compile of GWT does a better job at the end and it
would be better to take a look at other things to improve SDM?
I
On Tuesday, February 4, 2014 11:01:15 AM UTC+1, Cristiano wrote:
Anyway it would be great to find a workaround that don't require either
Flash or browser plugin or Java Applet...
Flash or applets wouldn't work, because a) they're going asynchronous too
(Flash at least) and b) they can't
No, really, the way forward is better tooling for SuperDevMode to provide
a similar experience to DevMode (i.e. never leave the IDE), and even allow
setting breakpoints and do step-by-step within JSNI.
Oh if this is possible than I'm ok, I was thinking that with SuperDevMode
I would had
Playing devil's advocate here:
I code in IntelliJ but I must say that I really like the experience that
the Chrome Developer Tools are providing.
From pure debugging point of view (stepping through the code) I actually
prefer the Dev Tools over the IDE because with the Dev Tools I can easily
Mozilla has stopped exporting some C++ symbols that the Firefox plugin
relies on [1]. Therefore it's not possible to support Development Mode in
any new versions of Firefox starting with 27.
As a workaround, I am doing one last release to get the plugin working
again with Firefox 24.2 (and
Hi Brian,
I wonder how does it works the development mode plugin?
Isn't it possible to replace it with something in pure javascript that is
based on Web Sockets?
Yesterday I was making some test with this technology (see
https://github.com/cristcost/gwt-websocket) and it it seems it has good
89 matches
Mail list logo
