Building RCP with support for Eclipse projects - java

I want to create an Eclipse RCP from our collection of already existing Eclipse plugins.
We have the pecularity that in our RCP we want the user to be able to open ("import") Eclipse projects (we distribute some of our features in bundles which come in the form of Eclipse projects. These should be registered in the workspace because a model server scans for the opened projects and loads them). Also, when I open files via File->open an exception is thrown from our internal editors: File opening intentionally only is possible if you load an imported resource.
For the moment, I have gotten the RCP to work by depending on org.eclipse.core.resources and org.eclipse.ui.navigator.resources. Thereby, I can import complete Eclipse projects. However, I am unsure[1] this is the correct/"intented" way of doing it (e.g. the navigator view is lacking icons per default) should I rather use the CNF?
The main thing is, we have to support loading/importing Eclipse projects in our RCP. Your answer is even helpful if you know other RCPs which allow to import Eclipse projects.
Regards
SuperUser
[1] http://wiki.eclipse.org/RCP_FAQ#Is_the_resources_plug-in_.28org.eclipse.core.resources.29_considered_part_of_the_Rich_Client_Platform.3F

If you are using org.eclipse.ui.navigator.resources then you are using the CNF (it's org.eclipse.ui.navigator).
The link you have is pretty outdated information, using the Eclipse Resources support in an RCP application will work fine (our product does it). And then if you want to package the application to work either as RCP or in an IDE environment you are one step closer. Also, despite what the link you provided says, don't be afraid to use stuff in org.eclipse.ui.ide if you need them. All you really need to be concerned about is to make sure you are only using classes that are actual Eclipse API, if you do that, then everything will work on future Eclipse versions. Anything that's public is Eclipse API unless it's marked in the Javadoc that it's not intended to be used by clients.
You should not be using the Resource Navigator as that has been deprecated and is not as general as the CNF.
As far as importing and exporting Eclipse projects with RCP, our product does that as well and it works fine.
I would say you are on the right track.

Related

How to identify a project (eclipse) type (RCP or other) to look at the code?

Please bear with me, if my question sounds bad.
I am working with a project (java eclipse), I had the code base in my office laptop, it works fine, now I need to get inside the code/project so that I can modify when needed.
I can code in java (intermediate level), but I am a beginner at eclipse stuff, specially eclipse application/plugins.
I am spending lots of time reading/watching different tutorials on eclipse (like vogella, o7planning, help.eclipse, etc.) but got confused on all these different stuff, RCP, SWT/jFace, Java GUI, windowbuilder, etc.
I need to know How "this" (my project that I'm working) got started? Is it a eclipse RCP? seems like a RCP, but there is no OSGi,
Here is a list of what it has (other than .java, JRE library, Plug-in dependencies),
META-INF, build.properties, a product file, a launch, h2 connectivity, a plugin.xml
From user point of view, this program has several menus, views,
I was able to open some views in windowbuilder editor (not all views/menus)
some java classes named as handler (part of name).
Any suggestions (reading materials) how to start with this project to understand it completely will be really helpful.
Is there any way to reproduce the whole project (using all the codes/java files that I already have)?
One way to do reverse engineering is by going through plugin.xml.
vogella is a good tutorial you will find all major eclipse rcp related tutorials.
You mentioned menu go through your plugin.xml you will find org.eclipse.ui.menus extension and associated handlers.
https://www.vogella.com/tutorials/EclipseCommands/article.html
Do your plugin project contains.xtend files go through https://www.eclipse.org/xtend/documentation/101_gettingstarted.html
Do your plugin project contains xtext files go through DSL
https://www.eclipse.org/Xtext/documentation/102_domainmodelwalkthrough.html

Register Bundles in the PluginRegistry?

I'm trying to load OSGi Bundles from an arbitrary folder at runtime in order to use them in my Eclipse RCP Application. The following steps I have done so far to achieve that objective:
Create a new Plugin
Acquire the BundleContext from the Plugin Activator
Install a Bundle via the install() method of the BundleContext
Start the acquired Bundle via the start() method
After these steps the Bundle is in status ACTIVE and can be retrieved via any BundleContext. My problem is that the bundle cannot be retrieved via PluginRegistry.getAllModels(). Apparently the PluginRegistry is not listing to changes in the BundleContext. I need find a way to register my Bundle in the PluginRegistry. This is important because the PluginRegistry is used by already existing software parts, e.g. the Manifest Editor.
The PluginRegistry has no method to register Bundles. Is there a way to add them to the registry?
The PluginRegistry class is a development time class supporting the PDE. Does this mean that your RCP application includes the PDE and is used (in part) for plugin development? If this is true, then you will need to work out now PDE works (which is something I don't know much about). I recommend having a look at the classes in the org.eclipse.pde.runtime plugin (not the internal classes). You should be able to work out with the debugger and looking at the code how to add a plugin to the PDE runtime. If you have further questions about that, use the PDE newsgroup at the Eclipse site.
If your RCP application does not include plugin development, then there is no need to work with the PluginRegistry at runtime, so I'm confused by your question. Perhaps you could elaborate more?
During the development of Acceleo, we stumble upon this problem too as we need to let the user deploy Eclipse plugins, located in its workspace, in the running Eclipse instance (we also need to uninstall those plugins after that). Since Acceleo is open source, you can have a look at our source code on github.
I won't detail everything here but you should find what you are looking for around the line 880 and after around the line 752. The file linked is our utility class for manipulation of Eclipse plugins in the workspace and Eclipse bundles in the running instance so you can find there pretty much anything needed to handle your problem.
Small warning, when we are deploying on the fly an Eclipse plugin located in the workspace, we deactivate its plugin.xml. Since most of the Eclipse tools are just looking at the plugin which are contributing to their extension point at a given moment and since they are not listening dynamically to the installation / uninstallation of Eclipse plugins contributing to their extension point (which can be done like this) they may keep references to contribution from plugins that we will uninstall later which can create problem. This behavior is explained in detail line 775 in the first linked file.
Regards,
Stephane Begaudeau

Dependency bundle (jar-files/sources/API docs) in Eclipse

I'm developing various in-house extensions for JIRA, the issue tracker we use. So far I worked with Netbeans and everything worked like a charm. However, now I need to switch to Eclipse and I'm having struggle setting up the environment for this development project.
First a clarification why I'm using the approach I'm describing here: building JIRA (in an IDE) is not easily done and I'm absolutely not interested in wasting my time to figure out how to do it. Besides, I don't need to build it, I just want to develop extensions and be able to use the IDE's auto-completion and help support (API docs). Atlassian (the company that develops JIRA) provides a "development" package, but it's just a sorry excuse rather than a real solution.
What I did with Netbeans was to create a library bundle with all relevant jar-files, the Java source files and the API documentation. This way I could use auto-completion, "jump to" the source and the API docs would pop-up when needed.
It seems Eclipse doesn't offer such a functionality, at least I couldn't figure out how to add the sources and the API docs to a "User Library" (which I'd then add as a dependency to my project just as with Netbeans).
My next approach was to create a separate project that holds all the stuff and mark that project as a dependency of my project. This works, but it leaves me with another issue: now I get 37k errors reported (all within the "dependency project"). As said, correctly setting up building for this dependency is a major struggle and not my original goal, therefore I'd happily ignore these errors. Automatic building is turned off and changing the "Errors/Warnings" settings under "Java Compiler" for the project didn't change a thing, so I'm kind of lost now.
Okay, let me try to phrase this as questions:
Maybe I just didn't find it: Is there a way to create a dependency bundle (call it whatever you want) in Eclipse that -- besides just carrying jar-files -- gives me the ability to use the API docs and "jump to" the declaration in the sources?
If not, what's the common practice to do in such a situation?
If the "dependency project" solution is the way to go, how can I completely disable compiler errors for that project?
Check this for illustration with images
Add the source code for jar
Add the Javadoc for a jar
Or just right-click on the jar file in the Package Explorer view. Select "Properties" then set the according paths in the "Java Source Attachment" and the "Javadoc Location" field.
When you create user libs via window->preferences->java-build path->user libraries you can specify which jar you need, sources (in archive or folder) && javadoc (from internet, or local, or from archive). Then you can use this lib in your project via context menu on project->Build path->add library->user library-> choose your lib.
Here you acn pick up more info Eclipse help

Open eclipse svn project in netbeans

OK my problem is quite simple
Im about to start working with a team of programmers, and we are using a svn repository to store our code, thy files are set up as Eclipse Project as the rest of my team all like eclipse.
However I am die hard netbeans man, I have tried eclipse Iv given it some time but we do not gel as they say.
So my question is there a combination of plugins /hacks that i can use to access a Eclipse Project from an SVN repository inside Netbeans , without corrupting the eclipse project or causing problems for the rest of my team (I would rather suffer eclipse than do this to them)
Many thanks ^_^
In NetBeans 6.8 under File > Import Project there is both Eclipse Project and Resynchronize Eclipse Projects. I'm guessing this can be used to work together with people using Eclipse.
UPDATE: How the eclipse import function works.
As NA pointed out, there is a way to import your Eclipse projects into Netbeans. However, arguably, you shouldn't be checking in IDE-specific files into your repository unless you can guarantee everybody is using the same IDE. Otherwise, I would recommend only checking in the source code, resources, and additional libraries and keep the specific files on ignore and have each individual setup their own environment.
Another alternative, is to check in the IDE-specific files in a different folder in the repository so that an individual can grab them if they need them.

Is Developing Maven war apps in MyEclipse worth it?

My organization has made an upper level decision to move to maven as the standard build tool for Java projects. I have been tasked with helping our local teams migrate projects over to maven.
One of the core tools that is in play is the MyEclipse IDE. MyEclipse seems to have had a "fun" history with the maven team as evidenced in various places, especially when dealing with war projects. I haven't encountered problems with simple jar projects...yet.
After fighting with MyEclipse and failing to make it recognize a war project easily, the question becomes, is MyEclipse worth it for developing maven war apps?
If so, is there a way to get MyEclipse to play nicely with a war project that I've not found? Or, am I simply better off suggesting its time to use Eclipse Java EE edition with m2eclipse?
No. MyEclipse does not support projects that were created outside of it. It is by design only working with projects created using its wizards.
From the Using Maven in MyEclipse Overview
NOTE: Maven is only supported for new projects. Migration of existing
projects to Maven-enabled projects is not supported at this time, but
may be considered for a later release. Right now the MyEclipse team is
focused on providing as fluid a new-Maven-project experience as
possible
I am working as a tech lead, and we recently started moving to maven. I had a couple of issues getting maven to work with myeclipse. First, even when I "Enabled all m2eclipse features" checkbox, I still couldn't check out a project as a maven project, from subversion. That option (that you get from m2eclipse) just wasn't available.
Also, some of the preferences you get with m2eclipse are not available with maven4myeclipse.
Finally, I couldn't just uninstall the maven4eclipse plugin and install m2eclipse. That would have been an acceptable workaround.
I think Genutec tried to make Maven more accesible to newbies, but there are some problems in the impementation, and I don't see them being fixed soon. For us, that will likely delegate MyEclipse to being just a fancy jsp editor.
Mike,
Sorry to hear you are fighting MyEclipse and Maven, in the past the most common problem I've seen causing people pain in this area is when they don't have the Web Root, Java source dirs or resource dirs set correctly.
Using this webpage as reference for a standard Maven2 web project layout, you can easily create a Maven-enabled MyEclipse Web Project. The steps you would want to take are as follows:
File > New > Web Project
Give your project a name, use the Java source dir of "src/main/java" and a Web Root of "src/main/webapp", check the Java EE spec level you want, check "Add Maven support" checkbox and hit Finish (unless you want to setup the artifact/group IDs).
Now, if this is the first time using Maven4MyEclipse, a lot of initialization will take place preparing your local repository and grabbing all the Java EE resources to build your project, but after that's done you should be all set.
You can execute the Maven targets off the Right-click Run As or Debug As menu and even manage custom goal execution using the "Maven build..." shortcut -- this is all similar to m2eclipse.
If you decide you want to use m2eclipse complete, you can navigate to Window > Preferences > MyEclipse > Maven4MyEclipse and check the "Enable all m2eclipse features" checkbox.
Out of the box we only hide the bits that can make Maven confusing for first-time folks, if you enable all the m2 bits, you can do whatever you want with Maven and MyEclipse. If you keep having trouble stop by our forums and let us know and we'll help out as best we can.
Mike,
think the issue is that the project has already been created outside of MyEclipse and >worked thru maven using the command line. Importing it is not successful.
I saw this post when looking for other Maven resources so I'll chime in.
Why not import your existing project using File > Import and turn on all the m2eclipse features and continue to develop it as you did before using maven commandline tools? I've done this and it works well for legacy projects, once m2eclipse features are enabled as mentioned in Riyad's #5.
Personally, I've always thought the maven war format was a bust, but we still have some old projects that use it around. Maven's format is just a default (and a poor one), not some sort of standard. However, we currently leave those old projects "as is" (using the above technique) just because it's easy. But for new work we use the MyEclipse web projects then just enable Maven support on them. The benefit is that you get all the Maven support and it's super easy to use and manage but no more commandline (although that still works too) and all the MyEclipse tools work perfectly on them as well. It's a "best of both" approach, well, at least for us. YMMV.
Hope that helps,
Dave
Mike,
Interesting, what happens when you have developers who are not using MyEclipse?
Not an issue here; I work for a very large company that has been standardized on it for quite some time (happily, I might add as we used to be a WSAD shop -- shudder.)
Anyway, if you have some that use MyEclipse and some that don't I see two options. First, if you create MyEclipse web projects and then "Add Maven capabilities" (or whatever it's called) to them, they'll work in MyEclipse and from the Maven commandline as well. So even if you're not using MyEclipse you can still use the commandline Maven tools. Also, since the MyEclipse structure is the more standard "exploded war" layout, it should work with whatever else you use as well.
Other thing to consider is that Maven's web layout is simply a default and Maven can easily support any project structure, including the one MyEclipse uses, so you should be able to use the MyEclipse project with Maven in any tool with just a little additional config. That's likely why the Maven commandline tools still work on the MyEclipse Web projects -- the MyEclipse guys just automatically configure Maven to recognize the format.
You also could just import the externally created Maven web projects as I said in my last post. We don't like to do that because that structure is unique to Maven and just doesn't work with any tools except Maven. As a result, it basically defeats the the tool support you get automatically in MyEclipse, Eclipse Java EE, or pretty much any other tool. It's just a poor default. Exploded WAR format, that's used by MyEclipse, Eclipse Java EE, WSAD, RAD, and everyone else is simply a better solution. Especially when it still works with Maven just fine as well.
Maven was made to be flexible to project structure. We've just found by using that flexibility a little you can get Maven support and great tool support too.
Dave

Categories