Im finding after a few weeks of GWT development my Development Mode compilations suddenly slow down at the stage where you see this in the Development Mode console log:
Validating newly compiled units
I've found a related question but this seemed a little vague compared to my issue
Eclipse getting too slow - workspace recreation helped
Since I lose window/toolbar layout settings (even if export/import prefs) and other useful things when I recreate the workspace I want to find out which files I can clean?
I've raised a bug with GWT..
Another answer which really solved it in my case.
Is it possible that you are operating behind a proxy which has to be configured in Preferences->General->Network Connections (e.g. for installing plugins)?
That's true in my case but I had deactivated the proxy settings to reach the in-house SVN. As it seemed, the Validation routine always tries to download ui binder XSDs without success which takes a lot of time.
Concerning my comment in my first answer: yes, it run a lot faster after reinstallation but the reason was that I had to activate the proxy settings for reinstallation. Once I deactivated it again for an SVN commit, it ran slow again ;-)
I have similar problems with Eclipse (Indigo Service Release 1 Build id: 20110916-0149)
and the GWT plugin. Especially when starting Eclipse, Validating the GWT components in my project takes ages.
Googling revealed that the GWT designer in combination with a 64Bit Eclipse Indigo causes this issue.
http://code.google.com/p/google-web-toolkit/issues/detail?id=6602
I wil try to reinstall the GWT plugin without Designer.
Related
When I'm using STS (Spring Tools Suite) 4, the autocomplete stops working for no apparent reason, and the only solution I find is to stop all my work, close the STS and reopen again. But this interruption is extremely annoying.
I couldn't find the cause of the problem. It happens randomly sometime after I start working. The autocomplete screen stuck like the image above showing that "1 pending" and it never finishes.
Version: 4.8.1.RELEASE
Build Id: 202010230733
This sounds related to https://github.com/spring-projects/sts4/issues/579, so please follow up on the GitHub issue with more details. Especially a thread dump of the IDE process as well as the language server process would be extremely helpful in debugging the fixing the issue.
As a workaround, you could go to the Preferences -> Java -> Editor -> Content-Assist -> Advanced and disable the Language Server Proposals. That will most likely help to avoid the problem (but also disables some of the Spring Boot related additional content-assist features for the moment) until we fixed the underlying issue.
This is a project I've been working on off and on for months and I feel like I'm pretty close, but I just can't seem to get past the final hurdle.
The goal is to develop an organization extension library that contains both internal and 3rd party code that we frequently rely on.
History
As a test project, I started with Apache Poi because that is already in wide use in our environment. I have a plug-in and feature built just from the Poi .jars that allows me to build our current Poi applications as long as I add the plug-in (from my workspace) to my build path. The apps work on the servers because we have already distributed the Poi .jars by manually copying them.
The next step is taking that plug-in and getting it into an updatesite so that all of the servers and developers can synchronize on one version. I found and followed these two excellent blog articles (that I wish existed when I started this project):
http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/
http://www.dalsgaard-data.eu/blog/deploy-an-eclipse-update-site-to-ibm-domino-and-ibm-domino-designer/
With the caveat that the articles are written for Domino 9 and we are running 8.5.3 here, but that only matters in the last (installation) step.
Current
This brings us to the problem. All of the above seems to have worked great up to a point. I can install my feature to my designer client from the eclipse update site and it works great. However, the install is failing when I import that into our updatesite.nsf database. This means that while the developers can all install from the updatesite if I put it on a network drive, that doesn't deploy updates to our servers.
The problem is that when I try to install from the .nsf update site, the Eclipse Updater just hangs. I've let it go for well over an hour and eventually Notes becomes completely unresponsive.
So the question is, is there anything I might have done wrong, either in the development of the plug-in or server configuration that might be causing this issue?
Additional Info
I'm looking at the osgi console and that is largely unhelpful. I am getting the following errors as I'm trying to install: SEVERE Could not access digest on the site: no protocol: 0/5B004DDD5E38F3FF85257CAF004C72C7/$file/digest.zip ::class.method=unknown ::thread=Worker-7 ::loggername=org.eclipse.update.core
I could generate dumps if that would be useful.
Security is also locked down fairly tight here. It could be a security issue - is there a way to troubleshoot that? Once I get to the hang I'm just stuck guessing.
This has been edited for clarity and to update information
I know that this is post is over 5 years ago but...
for those that find this and are trying to resolve the error
SEVERE Could not access digest on the site: no protocol: "
is due to the update site project not having the URL of the Domino updatesite.nsf not being added to the Archives tab of the site.xml.
I found the updatesite.nsf also needs to be anonymously accessible as no credentials are prompted/passed through to the Domino server hosting the updatesite.nsf database (at least from DDE), YMMV from eclipse. So if Anonymous connections are blocked on the Domino server you will be out of luck.
To develop a plug-in you really want to have 3 projects:
the plug-in
the feature
the update site
Of course a feature can contain more than one plug-in (and probably should) and a update site can contain more than one feature (and probably should). Once you have an update site project it features a handy button "build all" that makes sure plug-in, feature and update-site get compiled in one go. And that button is what you really want.
You can point using a setting in your Domino Designer (or local Domino server) to the feature directory. Add a plain text .link file to framework/rcp/eclipse/links, that contains the path to your install site - it then picks up the features and plug-ins from there. After a build you would need to restart designer/server to activate the updated feature.
For the Domino server the approach using an updatesite.nsf and the respective notes.ini setting makes the most sense (to me). http restart required. Lazy people script the whole thing.
I still don't have a great answer for this, but I believe the issue is related to the environment here. I don't have the authority to change the environment, even if I were able to conclusively demonstrate it is the cause of this problem, so it is a moot point. All I can say is that at least one administrator computer had no issue installing from the update site.
For me, the solution for distributing the update site is to put it on a network drive and have everyone install it from there. The server has no problem using it from the updatesite.nsf.
I just upgraded to the App Engine 1.7.6 SDK for my python app and realised that breakpoints no longer work in PyDev (Eclipse plugin) when using the new dev_appserver.py.
Does anyone know of a way of enabling them again? I assume the new server is spawning a new process for the web server, and the debugger isn't attaching to that one. I'm not sure how to configure it to do that though.
In the meantime I am using the old_dev_appserver.py server.
UPDATE 2012-07-27:
Following the comment, I verified, the issue is solved after updating to
PyDev. 2.8 and App Engine 1.8.2
OBSOLETE:
I found the following analysis of the problem at googleappengine issues tracker
The reason why PDB doesn't work is because dev_appserver is using
stdin/stdout for interprocess communication. Python has built-in
libraries for IPC: http://docs.python.org/2/library/ipc.html.
dev_appserver should use these, and then stdin/stdout can be left
alone so that PDB still works.
So it seems that there is no workaround, rather than reverting to use old_dev_appserver.py
UPDATE 2013-04-23:
Inability to debug is annoying.
Many developers complain about it
PyDev Breakpoints in App Engine 1.7.6 broken?
https://groups.google.com/forum/?fromgroups=#!topic/google-appengine/ep5BWYKpQpU
https://groups.google.com/forum/?fromgroups=#!topic/google-appengine/TCQuJpF44cY
https://code.google.com/p/appengine-devappserver2-experiment/issues/detail?id=28
https://code.google.com/p/googleappengine/issues/detail?id=9012
I am keeping track of the development of this issue here:
http://goo.gl/XRU01
Yep, ran into the same problem.
Open your Run/Debug Configuration and set the Main Module to:
${GOOGLE_APP_ENGINE}/old_dev_appserver.py
Do you mean pdb.set_trace() isn't working?
Look for the function MonkeyPatchPdb() in google/appengine/tools/dev_appserver.py
Run that somewehere in your own project before you use pdb and it should fix it.
I use the Hot Swap java debugging feature with web app on Tomcat. After some class signature change, I got "Hot Code Replace Fail" Eclipse dialog - I understand that.
What I want in such case is to republish the application (I can do that) and work with the newly deployed code. However the debugger stil complains, until I restart the server. Because other apps and long startup I don't want that.
Is there a way how to tell to the debugger, that there is the new class version already reloaded in a new webapp classloader and that it is save to continue?
Thanks.
Why don't you try with JRebel?
JRebel is a JVM Java Agent that integrates with application servers, making classes reloadable with existing class loaders. Only changed classes are recompiled and instantly reloaded in the running application.
JRebel plugs into IDEs and build systems. Classes and static resources are loaded straight from the workspace.
http://zeroturnaround.com/software/jrebel/
Regards,
Andrea
There is a old PHD project. The guy who made it was brought by Oracle but his work didnt made it to the Java 8 and hopefully will be seen in Java 9 but is more likely to be in Java 10. There is a new Version of this for Java 8 I guess. I havent tried it yet.
My Original Question for additional information: Advanced Code Hot Swapping in JDK 8?
And the Project page on Github: https://github.com/dcevm/dcevm
With this you can hot replace almost any class change freeing you from restarting the JDK ever after. (beside sideeffects for static objets and singletons but that would be logical)
Did you try Server Options - Serve modules without publishing along with Publishing?
Also not sure what you are saying about other apps.
I have been having a real hard time getting API Tooling to work in Eclipse 3.4.2. It keeps telling me:
The minor version should be incremented in version 3.4.0.qualifier, since new APIs have been added since version 3.4.0.40001
That being said, I have generated the plugins that are used for the baseline from the exact same code that it is being analyzed against. The API Tools docs say that it compares the current code against the baseline to see if there are any differences. I can't see how there could be differences if the built version is built from the current code.
The way that I tested it:
Create a new eclipse workspace
Create a new Plug-in Project with API Analysis turned on
Add a simple class to that plugin and export the package with that class in it
Build/Export that plugin to some location on your hard drive
Set the workspace baseline to that location and do a full build
You get an error for the project in your problems view.
Thanks,
-One very perplexed user
Looks like this is something that got fixed in 3.5. Too bad my company doesn't want us using 3.5 in case there are any incompatibility issues. (there were 3.3 to 3.4)
My recommendation to anyone who wants to do Eclipse API Analysis is to use 3.5.
First off, I apologize for jumping on a thread late after its "active time" but I am currently running into this exact situation, but with Eclipse Helios 3.6.
From your answer, you noted that something was fixed in 3.5. Are you aware of what this exact fix was AND if you have yet been able to verify that it is working under Eclipse Helios 3.6?
I would really like to have PDE API tooling working but I'm nearing my time allowed on this effort and need to move forward onto some pending tasks.
Thanks!
EDIT: I would have posted this in a followup link but did not see any such links available.