So I've been messing around with the packaging feature that NetBeans offers, following this tutorial: http://platform.netbeans.org/tutorials/nbm-nbi.html. I didn't like how I had to modify the platform that my IDE was running on in order to customize the installer itself, so I decided to create a copy and just change the platform the application suite was using (Properties->Libraries).
This seemed to work fine, and even packaged that platform as part of the installer. However, when doing the packaging itself, I noticed that it was calling the IDE's platform build script to create the installer rather than the one I had customized. This defeats the purpose, at least in my case, of having the separate platform.
Within the platform manager, under the harness tab, I made sure that the platforms harness was being used rather than the IDE's, but it didn't seem to make a difference.
I verified the behaviour by throwing an echo into both the default IDE platform and my customized platform to see which was being called. I also noticed that the Ant call that gets made at the start of packaging makes an explicit reference to the IDE platform, as well.
I've tried this under 7.2 (currently using 7.3) as 7.3 has had some fairly nasty bugs and thought perhaps it was just recently introduced.
At this point I'm thinking it's a bug, but I was hoping that perhaps someone else had come across this and found some sort of solution or could shed some light on why it's doing what it's doing.
Thanks!
This is slated to be fixed for 7.4, in case anyone comes across it in the meantime.
Here's a link to the bug ticket: https://netbeans.org/bugzilla/show_bug.cgi?id=229478
Related
I'm developing an Eclipse plugin and i've run into this problem several times already.
I always keep my Target Platform updated for the latest (stable) Eclipse release so that i test my code against all the recent updates, fixes etc.
However, this may (and have) result in accidental breakage of backward compatibility of my plugin, e.g. when i accidentally use new API that did not exist in the Eclipse version i aim to support.
Or, more sneaky example, in 4.6 Eclipse moved to Java 8 and some interface methods got default implementations. Now when i implement these interfaces my IDE doesn't automatically generate empty implementations for those methods and no error is generated. If i install and run this code against a previous Eclipse version these methods will throw AbstractMethodError since no implementation has been provided.
So my question is: is there a tool to further restrict API my Target Platform provides to some earlier Eclipse API version?
Is API Baseline an appropriate tool for this? Because i couldn't get it to work like this. (It allowed even non-baseline method calls not to mention the more complex default-methods example.)
You can use multiple target platforms, switching between them doesn't take long. For testing Stack Overflow questions I have one Eclipse install with 10 target platforms.
So have a target platform for the oldest release you want to support as well as your current release target platform and check the code runs against that.
It is particularly important to test with the actual Target Platform if you want to support Eclipse 3 releases as the were large changes going from Eclipse 3 to 4.
I'm doing Udacity's Web Development course. I've heard some users talk about Eclipse, but I'd rather have a basic understanding of the command line than move on to that higher level software.
Is there anything on a Mac that I can't do in Terminal that I could on Google App Engine Launcher?
Thank you.
The gcloud commands from the Cloud SDK provide much more control over your experience. The App Engine Launcher actually causes more problems than it helps with. In the long run, you're much better off with gcloud.
If you wanted to use an IDE, there are new plugins for Eclipse and IntelliJ. If you wanted to keep debugging simple, you could just use the command-line PDB debugger.
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.
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.
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.