I have some questions regarding the eclipse update feature functionality. In generally,what eclipse update is doing is,if it is installing new software it is copies the jar from the specific URL and paste it into the eclipse plugin folder. So If I create my own update functionality to copy from the specific URL and paste into the eclipse plugin folder, will that be enough to finish the job of update site? My requirement is I need to create different look and feel for the update functionality. I don't want to use the UI of eclipse update functionality. What's the correct way to implement update functionality? Please correct me if I am wrong.
Assuming we are talking Eclipse 3.5 or later, then you will be using p2, so have a look at Customizing the p2 UI.
It is not generally enough to "just" copy stuff to plugins/, as that will not get OSGi to install the new bundle. Use p2 to install your stuff, as it will do the right thing.
As for a completely different UI experience, have a look at the Eclipse Market UI...
Related
Really basic question here but this has always stopped me from using any JetBrains product, but here I am trying once again. I also have the same issues with CLion but that will be for another time and hopefully I can figure it out based on some feedback from this post.
I need to set up my environment in IntelliJ. Nothing special. No build tools. Currently I just run my school projects using
javac Main.java
java Main
This has gotten me so far but I really want to use IntelliJ tools to their full capacity.
I want to be able to set break points and step in and out of my code in their debugger and all the other nice tools that come with running my code through IntelliJ
Every get started tutorial that I have watched on YouTube or from JetBrains themselves already has a basic build configuration set up to run your basic "Hello World" application and that is what I think I need. Just compile my java files into classes and run/debug them.
This is what the run configuration icon in the IDE should look like
And this is what mine currently looks like
I have set many different JDKs to go along with my projects but none of them seem to get the tools I need set up in the IDE. I have even let IntelliJ download one for me and set it up itself to see if maybe I downloaded and installed it wrong and IntelliJ maybe wasn't recognizing it.
This picture below is showing the project structure for an application that I let IntelliJ download a JDK for and set it up itself
So if someone could help me that would be fantastic. Links to videos, blogs are welcome even though I know that isn't the convention on this forum but I think that would be sufficient for my situation. Thanks in advance!
---Update---
I have found that if I create a project in IntelliJ that I get all the default configurations that I need. The problem is when I need to get a project from VCS that I am not getting any of the configurations that I need to run/debug my program in IntelliJ.
The easiest solution here would be to click the green play button next to your main method, on the left where line numbers are displayed.
Intellij will configure a default java run configuration for you. It will be displayed in the menu for later use, like in the screenshot you posted, after your first run.
You can also create one using the to menu: Run > Edit run configuration to add some more options like arguments, environment variables (that only apply for the run config), etc.
A good starting point would be the Intellij help page on that topic. This help pages are always a good start and you find comprehensible instructions there on every topic.
Another good resource is the Intellij by JetBrains YouTube channel. This video about debugging shows both ways I described above. They have lots of quick tutorials about lot of features, like code generation or build tools. Check out the channel's playlists for specific topics.
Update
The problem with the already created project is that the default/ folder is not marked as source folder. You can do that by File > 'Project Structure...' and set the default/ folder as Sources:
The cause for intellij not recognizing this is because you didn't use a folder structure like the one of maven.
For source code:
src/main/java
src/main/resources
and for tests:
src/test/java
src/test/resources
If you set it up that way IntelliJ everything works as expected. I created a pull request to your repo. If you check out the branch, IntelliJ will setup everything correctly automatically.
I am trying to create an eclipse plug-in for an existing SDK. My main goal is to allow user to create a project that will automatically have the SDK jar file and will also load couple of examples. The main purpose is to free the user from the hassle of adding jar file and looking up the examples.
I am fairly new to this area of development. I have never created a plugin and was wondering if there are any specific tutorials or development guide for creating such a plugin.
Any help is appreciated!
It's a bit unclear what your requirements are, what the SDK are, what type of users you developing for. But the simplest solution would be to create a set of Eclipseprojects with a proper setup. Then your user would just import them and continue to build from them.
A more elaborate solution would be a new project wizard. So when the user goes to file -> new project, they will find a specific wizard this type of development. If this is what you are looking for, then this tutorial will offer a good starting point.
What is the right way to make an RCP application that is “ready for plugins”? I have struggled to do this basic concept and am trying to accomplish this in Eclipse 3.7 (latest 3.x version).
Step 1
I would like to explore this by using 3 eclipse plugin projects:
• HelloWorldRCP
• HelloWorldPluginA
• HelloWorldPluginB
Would it make sense to make HelloWorldRCP with all the common things such as a menu-bar with an Edit menu including cut, copy and paste menu items? The HelloWorldPluginA could add an additional menu-item called “Alpha” and HelloWorldPluginB could add yet another menu-item called “Beta”? However, the cut, copy and paste functionality could still work within Plugin A and B?
Step 2
Next, how do I deploy this as a “product”? I have made a new product configuration and defined the dependencies from the default runtime configuration that was made. I do notice that there are a lot of dependency jars that are included, but I don’t think I use them. For example, I don’t use data-binding to my knowledge, but it keeps coming up as a required dependency.
I go to Export | Eclipse Product and an executable environment is created in my desired folder. However, when I copy this to another machine it seems to keep referencing the original machines Java installation location. How does one get around this?
I have tried to bundle a jre with the Product Export but nothing is created. I have also just tried copying my jre6 as a jre folder. This does seem to work.
Next problem here is the 32/64 bit Java execution environments. What is advised here? I have been aiming to build on 32 bit only and then hopefully that will run on 32 or 64bit platforms. Is this correct?
Step 3
I need to web-start this now. The old way of initiating an Eclipse 3.5 application, using a startup.jar has changed. I now use the equinox launcher and reference it in the jnlp instead of the startup.jar. However, I keep getting an exception which seems related to the 32/64 bit equinox win32_64 jar. I notice that the export writes a folder and not a jar. I read somewhere that this is a “clever trick” to allow compatibility for both 32 and 64bit runtime environments.
The problem here is that I need a jar and not a folder so that I can sign the jars required and deploy accordingly.
Does anyone have a Java Web-start example for and Eclipse 3.7 RCP application? Or any advice?
You are going to need a lot of time to learn everything you've asked about here.
Here is one of the best places to start... http://www.vogella.com/eclipse.html
That site covers a lot of basics. But you need a little more than basics.
The best example of a working RCP product with some of the features you require can be found at ... http://max-server.myftp.org/trac/mp3m
This guy (Kai) makes all of the source code available via SVN, and he has some very advanced stuff going on in his application. He also has a good blog with some advanced RCP tips and tricks. http://www.toedter.com/blog/
Another thing you'll want to investigate is Tycho. I realize that you didn't mention anything about building your application, but I've found that using Tycho for building has made my most recent foray into Eclipse RCP 100 times better than the other times I've done RCP work. So, my advice, get to know Tycho. http://wiki.eclipse.org/Tycho/Reference_Card
The learning curve of Eclipse RCP is somewhat steep, but I think it's worth the effort.
Good Luck!
I recently wrote an Eclipse plugin, and I'm trying to get some coworkers to install it for testing.
As far as I can tell, dropping the .jar into the dropins folder in Eclipse is supposed to install it, but it seems to not be working on any installation of Eclipse but the one I developed on. This seems to be a problem with the dependencies not being installed.
I thought that the dropins folder was supposed to automatically calculate and install dependencies, but perhaps I'm wrong. If so, how can I distribute it without having everybody install each dependency separately?
I'd recommend against using the dropins folder. It is unreliable as you have seen. Instead, I'd recommend that you export your plugin as an update site.
So:
Create a feature for your plugin. This is a lot simpler than it sounds. See Lars Vogel's tutorial: http://www.vogella.de/articles/EclipseFeatureProject/article.html
File -> Export... -> Deployable Features.
In the options, section, select "Package as individual jar files..." (see screenshot)
Tweak other things as required
Finish
Now, you have an update site that you can zip up, or put on a web server somewhere. Your colleagues can add that update site just like any other. To install, make sure that they also have all of the dependencies available from other update sites and that they have "Contact all update sites..." checked.
The nice thing about this is that if you place your plugins on a web server somewhere, and you replace it with a new versions, people will be able to update transparently.
I'm wondering how Software Development Team distribute their Standard IDE(s)?
E.g. developing with Eclipse, custom Code formatter, svn Resository, Copyright Header..
At the moment my Team has a standard zip File which is then distributed withhin the developers.
Problem:
If one file, a Plugin or the IDE itself changes, e.g. new Coding Guidlines, Upgrade Eclipse 3.5.1 the whole distribution has to be done again. Every developer needs to unzip the bundel again. Imagine your working with different Workspaces (Jetty, different Tomcamt Versions, WTP) due to Project History That doesn't scale
I know that there are some related Articels
A new version of Eclipse just came out. Is there anything I can do to avoid having to manually hunt down my plugins again?
Manage Your Eclipse Install With A Local Git Repository
And some comercial Programs.
Eclipse also has a new Update-Installer Approach
But I don't see the Killer App. How do your team solve this? Is there a best practice?
I guess best would be a Program letting you choose your current Project and then downloads the configured IDE from the Server and leting you know if Project Config Files are Updated
For eclipse look at Buckminster it targets exactly your target I suppose, didn't use it personally through.
At my previous company they wrote a custom update agent that pulled from a centrally configured server which was updated by the team leaders. It worked well, until people wanted to install their own plugins.
Basically, a developer wanted a plugin, fought in futility to get it included in the default (managed) repo, installed it himself, then updates broke on his machine when the team lead had a sudden stroke of common sense and included it.
They never did come up with a 'good' way to manage it. But, at least they didn't put us all on terminal servers with thin clients.