Extending an existing product using Eclipse Oomph - eclipse

I'd like to create a new product for my own usage which extends Eclipse Neon ( or possibly Oxygen ).
I know that I can manually add update sites and UIs using Oomph, but I would rather like to define a reference to an existing product - like Eclipse IDE for Java EE Developers - and then just add some other features on top.
Is that possible using Oomph?

This is done by adding product requirement to the setup
<p2:Requirement
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:p2="http://www.eclipse.org/oomph/p2/1.0"
name="epp.package.jee"/>
Note that you still might need to bring in more features manually, see Extending 'Eclipse IDE for Java EE Developers' brings in fewer features than expected for all the details.

Related

Eclipse e4 migrating 3.x plugin to 4.x?

I have been working with Eclipse RCP for over a week now, and I've now been given an Eclipse plugin written in 3.x, which I need to migrate to 4.x. I'm using a book called Eclipse 4 RCP by Lars Vogel which has a small section on this, but I can't for the life of me figure out what I'm to do.
I'm trying to do this throught the use of the compatiblity layer. It mentions to add a couple of features for this (org.eclipse.rcp, org.eclipse.emf.ecore, org.eclipse.emf.common) and your ready to go, but I don't exactly know what I'm to do here. Like do I add these to the existing product file of the 3.x plugin I've been given, or do I create a separate e4 project and point to that. Many of the tutorials I read are a bit vague with the details and its a shame there's no proper step by step guide for beginners with this. Any help would be great.
Probably, you should be creating a separate e4 plug-in project for this. And where you have to configure your extensions/extension points in e4 ways.
Basically, like creating a new project.
If you want to migrate your Eclipse 3.x RCP application to the Eclipse 4 programming model, you can't directly reuse existing plugin.xml based user interface components, e.g. Views or Editors based on the definition in plugin.xml .
Components based on the plugin.xml file must be adjusted to avoid inheritance of Eclipse classes and to use the programming model based on #Inject . They also must be contributed to the application model.
Components which are not directly based on the plugin.xml file must be adjusted if they use Eclipse 3.x singletons, as for example Platform or PlatformUI , to access Eclipse API
you may want to take a look at this page: https://www.eclipse.org/community/eclipse_newsletter/2013/february/article3.php

Moving to Eclipse RCP from Eclipse plugin development

I am working with Eclipse Plugin development since 3 year but now i want to move to Eclipse RCP and RAP. I had tried and found it is bit similar and common things to work.
Now I want a better way to start with RCP and RAP. please share me what are the points that i have to take care and please share me some good tutorial link.
I had tried to search over google but getting a quit sure shot link.
There are no real differences between RCP and Eclipse IDE applications, except maybe a reduced set of plug-ins to rely on (but they can be brought back). What you might have to take extra care is branding (and theming), and packaging (possible via products). Some RCP tutorials to start with:
Eclipse 4 RCP
Old, 3.x RCP API
Products and deployment
In case of RAP, the difference is bigger, as you have to manage the different sessions of different users, and theming is more important. A tutorial for the RAP-based issues (including tips for single sourcing RCP and RAP applications) are available from eclipsesource.com.
A final note: if you are starting a brand new project, I'd rather experiment a bit with the 4.x API, as it is simpler to manage between RCP and RAP.
Another source of information about Eclipse RAP in particular is the official RAP Developers Guide which can be found on the Eclipse Foundation website:
http://eclipse.org/rap/developers-guide/

Integrating community plugins into a ready Eclipse RCP app?

I already have a standalone Eclipse RCP application. The next task is to integrate the plugins which are widely used in the Eclipse community like CDT or say PyDev to provide the editing and debugging facilities in respective programming languages inside the already developed RCP app. Just wondering how do i go about accomplishing this task. Should i start with playing around the extension points of the plugins and adding it to the MANIFEST.MF ?
What are the various ways of achieving this ? Which one to pick over the other?
The most important thing you should consider (besides the technical) is a conceptional.
Plugins like CDT are making a lot of assumptations about their environment they are integrated into. That means your RCP should have a very similar user-interface and behavior like the normal Eclipse SDK so that the integration of other "IDE-ish" plugins is not a break of the interface principles of your RCP.
If your RCP is not based on a common navigator, projects, files (in general the Workspace) and several editors the integration of Plugins like CDT will be a nightmare for your users and will feel like another application within your RCP.
Make also sure that ui-contributions from third-party-plugins are visible (e.g. if the third-party-plugin is contributing a preference page, make sure that your RCP has the menu-item to open the preference-window)
First you have to load the new features/plugins in your existing RCP application. For this you have to adapt your product definition and load the new feature.xml files. or you enhance your own feature.xml and place the new plugins into.
Afterwards you have to decide, whether the new functions/view/perspectives are contributions to an already existing RCP extension point and whether you use this extension point in your RCP product.
If you want to use the new functions in another way (because the default is not enough) you have to point to specific views/actions in the new plugins and call them by your self. Fot his you have to adapt the MANIFEST.MF of your own plugin and point to the new plugins. If you do it, you can not switch off the added features, because you do have a jard link to these plugins.
Your RCP product already depends on the RCP feature (org.eclipse.rcp) or a subset of its plug-ins. This means, it already includes the plug-ins defining the basic extension points.
To include functionality (extensions) from additional features, just add these features to your product configuration dependencies. For example, you would have to add the feature org.eclipse.cdt for CDT and org.python.pydev.feature for PyDev.
The hard part begins when you need to include only some of the features' plug-ins.
You'll have to isolate the plug-in(s) providing the functionality you require.
For UI contributions, you can use the plug-in selection spy by selecting the required UI part and clicking alt+shift+F1.
For non-UI contributions, information for contributed extensions can be found in the plugin.xml files in the plug-in sources.
These plug-ins, along with their dependencies can be added to a custom feature, which can be included in your product.
Although dated, the article Building a CDT-based editor might also be of help.

Eclipse GUI bundle

I am building an application whose GUI should look like eclipse. Since Eclipse uses Equinox OSGi framework, is it possible to reuse the bundle responsible for Eclipse GUI in my application? If so, which is the bundle which is responsible for Eclipse GUI?
Any help is appreciated..!
I believe you are making a wrong assumption: Out of the many bundles (a.k.a. plugins) that an Eclipse installation normally consists of, there is not a single bundle responsible for the overall GUI. Instead it is a large chunck of dependent bundles for the SWT graphics library, the views, workbench and so.
So if you want to create something that looks like Eclipse and behaves like Eclipse, then you want to reuse many of those plugins and you probably want to read further on the Eclipse Rich Client Platform, which is the smallest set of reusable bundles for creating Eclipse-based applications.
For building Eclipse-alike application you can of course extend the Eclipse platform using an own plugin. However OSGi can be very complex.
If you only want the general look of Eclipse you just use SWT: The Standard Widget Toolkit. This toolkit provides the GUI elements and is responsible for the look of Eclipse.
This is possible but a bit complex. Download the archives for SWT (basic building blocks like labels, buttons and tables) and possibly JFace (high level UI components) and add the JARs to your classpath.
One way to get them is to download Eclipse for your platform; that gives you the JFace JARs. SWT is a bit more complex because it contains one JAR per supported platform; you can find the JARs for all platforms in the "Delta Pack" (download for Eclipse 4.2)
When writing your application, you will need to determine the platform and add the correct SWT JAR to your classpath. Here is the code to do that: Create cross platform Java SWT Application

Why can't I find Java desktop application in Netbeans 7.1

I downloaded Netbeans 7.1 with all bundle from http://netbeans.org/downloads and installed it successfully on Windows 7.
But I can't find Java Desktop Application which should be under Java category when add new project as 7.0 does.
Where is it? Or what is the substitute one in 7.1? I need something to create GUI by dragging components.
Thanks.
Look here: http://netbeans.org/bugzilla/show_bug.cgi?id=204661
Support for [B]SAF (JSR 296, basically the framework that was behind your "Java Desktop Application" project template) has been abruptly dropped (for no valid reason, let me add).
However, as Bill says in his answer, it is not necessary to use the SAF in order to visually design a form. NetBeans swing-designer (known as Matisse) can be used to design any JFrame, JDialog, JPanel, etc.
You just have to
Right click -> New -> JFrame Form...
and you're ready to drag-and-drop!
(The features you'll be missing are the extra bells and whistles that such framework provided, like SAF Actions, windowing persistence, simplified management for long running Tasks and related visual feedback [now you have to get your hands dirty with the SwingWorker class], etc)
Java Desktop refers to an effort to create a standard or library (libraries) that never really produced anything of significance. I think its likely that they finally removed it from Netbeans.
Its easier to just create a new Java Application project, don't bother with a main, then create a new JFrame Form. That class will have a main for you to use, and you can also design the frame in the form. You can also create JPanel Form classes. Note: you can do this in just about any project in netbeans, there is nothing special about the projects for them.
its better to use NetBeans 7.0 for full support of swing components.
many tutorials and guides feature the "Java Desktop Application" (like the ones for JXMapKit : http://today.java.net/pub/a/today/2007/10/30/building-maps-into-swing-app-with-jxmapviewer.html )
You can find something helpful to create CRUD desktop application in Java.
You can find it here.