I am following the following blog to configure my golang environment (OS-X machine):
http://webapp.org.ua/dev/intellij-idea-and-go-plugin/
But, whenever I try to add go sdk (installed at /usr/local/go), it appear blank selection for the SDK.
Please suggest me, if I am missing something.
This page lists the SDKs which have already been configured in IntelliJ IDEA. You need to press the "Configure..." button and point the plugin to your SDK installation. Once you do this, it will become available in the SDK list for new project creation.
I would suggest to use the following for writing golang application:
https://groups.google.com/forum/#!msg/golang-nuts/tuGS99f-kqk/Tl5KqNG0js0J
https://github.com/visualfc/liteide
If you want to use IDEA with golang, we've made a lot of progress in the past months. Please install the latest release from github releases and give it a try.
As the name suggests, there are a few issues here and there but it should work much better that the current release of the plugin.
You'll find it a class over the other offerings for writing go apps ;) (disclaimer I'm one of the contributors to the plugin, I'm very biased)
Related
I upgraded Eclipse and moved to Google Cloud Platform for Eclipse for my existing Standard App Engine project. I also moved to Java 8.
Now, when I deploy my app, the size shown in the console is only 7.1mb vs. 220mb prior to the upgrade. And when I try to go to the app after deployment I get an Error: Not Found message.
Is there something in the setup for my new configuration that would be causing this?
Your question is indeed somewhat broad; you'll need to provide all necessary detail. A correspondingly general information page might help here, though, namely Eclipse "How-to Guides".
Have you adapted and re-written your app for Java 8? If so, in which way? Have you edited your app.yaml configuration file accordingly?
Cloud Tools for Eclipse writes out the app-to-be-deployed to a directory in your workspace called <workspace>/.metadata/.plugins/com.google.cloud.tools.eclipse.appengine.deploy/tmp/<timestamp>/staging-work/exploded-war, where <timestamp> is the time of the last two deploys. Look at the exploded-war directory and see what files are missing. You may then get a better sense of what needs to be remediated.
Recently, I wrote a cross-browser plugin using Firebreath, and I made one installer for all browsers. I searched in stackoverflow for automatic plugin installation, and find a bunch of good answers,
FireBreath plugin automatic installation
Deploying a Firebreath plugin on a webpage without manual installation
Plugin Installation
Deployment of NPAPI plugin with minimal user steps
All answers points out that it needs users’ interaction to download and install the plugin.
My question is that does plugin upgrade follow the same process of first installation, which let users to download the latest installer and install it manually again? Is there any other options to make the plugin upgrade more automatically (less user interaction)?
I also searched this answer a little bit relevant, but it doesn’t tell the way to upgrade a plugin automatically.
firebreath plugin refresh after update
Or I should ask what is the best practice to upgrade firebreath plugin?
Basically there is no good answer to your question, unfortunately. I have had in-place updates working for all browsers (updating in the browser without a restart), but it's fraught with difficulty and extremely fragile. I don't really recommend it.
Probably the cleanest update experience I've seen is by using Google Omaha to do the install and automatic updates in the background. The biggest downside to Omaha is that it's a beast to get set up and working; even just building it requires a lot of work, and then you have to customize a lot of constants and such.
The way I do it is just require that the user download and install an update (MSI or .DMG w/ applescript, depending on the platform) and then just tell them they'll have to restart their browser to get the new version. It's not clean, but it drastically reduces the support requirements.
I'm trying to get up and running with Virgo, and I'm following along with what appears to be an excellent tutorial, but I'm at section 7.2 and I just can't figure out why EclipseRT / Virgo doesn't appear in my list of options.
So far I've been using SpringSource Tool Suite (STS) as the guide recommended and have installed all the Spring dm Server Tools and Developer Resources bundles.
Has anyone else run into this issue or have a solution to getting the EclipseRT/Virgo server adapter?
Virgo 2.1.0.RELEASE and STS 2.5.0.RELEASE are both now out. The problems you had with the docs should be resolved. The documentation has also been updated to show the latest information as well.
Be aware that the STS 2.6.0 upgrade removes this server adapter! Refer to the STS JIRA entry STS-1690 for details on this removal. You can simply go to the Dashboard > Extensions tab and select "dm Server Support Extension" to put it back.
Hey, have a look at this eclipse forum for virgo
Seems like you have to get used to playing with the update sites until you find the right one. I imagine that by the time anyone reads this the url will probably have morphed every so slightly yet again. Sigh. Comes of playing with tech while they're still actively releasing.
In case someone is searching for more recant information, one need to install DM Server Tooling from http://dist.springsource.com/release/DMS-TOOLS/update to get Virgo in the server add dialog.
I've been just playing around with Virgo 2.1.1 and Eclipse STS 2.7.1.
Indeed there is no Virgo server adapter, but you can install it from this update site:
http://download.eclipse.org/virgo/milestone/IDE
For the latest version of STS (3.1.0), I tried many ways suggested, and find only the Eclipse Virgo/Tooling wiki works.
(http://wiki.eclipse.org/Virgo/Tooling#Install_Eclipse)
It adds the EclipseRT/Virgo adapter in STS 3.1.0.
I've read a lot about IBugTraqProvider interface and implementing an issue tracker into the commit dialog of TortoiseSVN.
IBugTraqProvider is written here.
Is there a more simpler way not to do it, building the plug-in and installing it on TortoiseSVN. The Document is not that clear that a developer can create its own plugin.
I'm working with SalesForce as the Issue Tracker, and retrieved the WSDL file to integrate with the Working Items. Now I need to know how to connect it to TortoiseSVN.
Please any suggestions?
Take a look at issue-tracker-plugins.txt in the contrib directory in the TSVN source code. There's a fairly decent example in C# that should get you heading in the right direction.
When I built a plugin, I built a test harness that passed arbitrary information using the IBugtraqProvider interface, so that I could debug the plugin whilst building it, without having to reinstall the plugin into TSVN each time.
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.