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!
Related
I have downloaded fresh Mulesoft studio and changed configuration to point Open JRE- 11 and compiler to point 11.
Studio version - 7.8
When I try creating the mule project it is now also adding module-info.java along with mule.xml files.
Wonder why it is creating module-info.java I don't used to see when i was working with 1.8 version or before.
Any Idea ?? Thanks in advance.
Java 9 introduced a whole new level of encapsulation. Larger than packages, and more robust too. These are modules.
Chances are you should in the long term, migrate your project to use modules (for additional security, and for better code organization). However, the chances are also high that you won't want to do it right now, just because.
In that latter case, it would be reasonable to simply delete the module-info.java file. Provided you don't have any other module-info.java files in the system, and provided you run with everything on the classpath rather than module path (there's a good chance that's your default anyway) you should not have any problem.
Meanwhile, you have some homework to do, so you can decide if you will migrate to modules, and if so, how to do it.
I have been having trouble utilizing Javafx within Intellij. I run into the error "JavaFX runtime components are missing, and are required to run this application" that I see a lot of other people have.
My main question is do I need to download Javafx12 sdk. I am able to use Dr.Java to run some of my old javafx projects just fine after adding an extra class path and I haven't needed to downloaded anything. It doesn't seem like I need to download anything as another much more basic IDE is able to run javafx. So why does it seem like intellij requires an extra download?
If you moved to Java 12, then yes, you need to download the JavaFX 12 from their new website https://openjfx.io. Luckily installing it is pretty straightforward and well-explained.
It worked before because JavaFX was shipped inside the JDK distribution, which is no longer the case. Swing however is still there and will work as before. (I am not saying you go back to Swing, just that it is still shipped along the JDK)
I'm using Mule Server 3.8 EE which brings commons-lang 2.4 with it. A third-party library in my project needs commons-lang 2.6, because it uses a method that was introduced in this version.
So when I just start my application, I get a java.lang.NoSuchMethodError
Is there a way to update the dependency in the runtime? What I tried so far:
including commons-lang 2.6 in my app -> no effect, the one from the runtime is picked up first
replacing the jar directly in the runtime -> errors in studio, that the 2.4 jar is missing
so maybe i am late BUT -- this is your answer. Add the libraries that are newer in the jar distribution to the Build Path. Under Java Build Path screen you should see the libraries listed. I needed to use Apache http-client 4.5.6 and that's very interesting because it brings with it a lot of other dependencies, so your question was VERY relevant. The solution is to rely on JAVA (and not mule -- oops Anypoint or whatever) conventions and make sure the JVM loads my class files first. Then, it won't load the old ones from mule's jar. And so I went to the tab Order and Export, and moved Mule to the bottom. This simple, trivial change makes it work. I think if we would work with command line and vim, we would all know this. But all the IDE gui and everything else makes us forget the simplest things. Please use it in good health. :)
As far as I see every time I make a change, for example the value of a configuration variable, I have to
Make a copy of the change in each project (webapp, Android, IPhone, etc.)
Build each project
Distribute each project (besides the webapp)
I have found PhoneGap build which seems to be a great solution for the mobile part. But it's still beta and it doesn't solve everything. I still have webapp's code, which is not exactly the same.
Do you know techniques, tools or tricks, which help to improve this process?
Thanks in advance.
We are currently developing a web/Android app using PhoneGap and Sencha Touch (iOS is coming soon). So far our approach is as follows:
We have one project per platform plus several additional toolkit projects.
One platform is "primary", web in our case. This is what developers mainly use to develop and test the app. We're using jsTestDriver for testing.
During the build, the app is packaged for web in the first step. We're producing several artifacts here (.war file, tests in a .jar file).
"Secondary" platform projects do not include the source code. It gets unpackaged and copied to the right places when projects are built. This also includes tests from the primary platform.
Platform projects contain some additional code - normally only testing code, app code itself is currently cross-platform (not sure if it will stay this way).
So we're doing it mainly through advanced build scripts. We're using Maven for web and Android. iOS is coming soon (into our work, I mean), so we'll be looking for some sensible build tool there too.
We're building our projects using Hudson continuous integration.
What I have to admit is that this whole environment (multi-project Maven builds, JSTD, multi-node Hudson) is a hell of a setup, took quite an effort to figure it out.
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.