The problem is, that this package and its children are not seen in the list of packages of "import". When I import all pde packages, org.eclipse.pde.internal somehow becomes usable anyway. But I don't see its sources. How can I manage this package?
Here are some rules from the Eclipse community that might help:
Package names should match plug-in names. If they don't strip from the right. The code you seek should be in the plug-in org.eclipse.pde.internal (doesn't exist). Strip internal and you get an existing plug-in.
OSGi allows to hide packages in plug-in X from other plugins. This feature isn't really used. You can still import the classes but Eclipse don't show them in code completion and you will get warnings. There is an option for the OSGi/bundle classloader to throw NoClassDefFoundError but that option is usually disabled. You can find the exports list in the MANIFEST.MF of the plug-in that you try to import from.
Most of the non-exported packages are in below a package internal, so this is a hint: Don't use this code. It's not part of the official API. It can change in the next version of Eclipse or the plug-in and nobody will care if your code breaks (unlike with the official API).
Of course, the world isn't that simple. Which is why using internal code is frowned upon but the classloader option is disabled (= Eclipse could enforce this behavior but they don't).
If you think some internal API would be great to use, file a bug report at https://bugs.eclipse.org/bugs/
The problem was solved by my colleague.
org.eclipse.pde.internal is in org.eclipse.pde.ui.
Eclipse 3.7.2 simply haven't the PDE sources. Appropriate directories in repository are empty. I downshifted to 3.7.0 and it is OK now.
Related
I'm currently trying to write my first own library. It's just for testing, I want to find out how libraries are written, compiled, distributed and used in order to prepare for some upcoming personal projects.
Yet, what really causes me to wonder, is why exactly my Javadoc isn't compiled with the Library. I know that comments and annotations are not compiled, but for example the JDK (which is basically a huge library) comes with a working doc as well.
I've tried to compile a JAR (libraries aree normally JARs, right?) from not the compile output, but the sources (so I had a JAR of .java files), but this failed to be included in IntelliJ. I could add it as an external library, but neither did it show up in my explorer, not could I import or use any of my classes.
I know there must be a mistake somewhere here, all libraries I've ver used, whether it was Java, C# or whatever else always came with a working documentation (IntelliJ shold show that on mouse hover), and I'd like to know how to correctly build a library that I can share with a team partner, so he just needs to download it, add it as a library in IntelliJ and has all the functionality, but also the documentation.
Thanks to everyone in advance!
Because it isn't needed, and would bloat the file size of the executable. If you have a library in C or C++, the documentation may be bundled in a zip file, but you won't find it in the compiled .so or .dll. One just holds the binary and resources needed for the project. The .jar is equivalent of that- it's the compiled output. Documentation is hosted/downloaded separately.
When you download the JDK, you're not just downloading a giant .jar. It includes other things, like documentation in the download.
I'd like to know how to correctly build a library that I can share with a team partner, so he just needs to download it, add it as a library in IntelliJ and has all the functionality, but also the documentation.
The short answer is that you provide your team partners with your project source code as well as the binaries. They then can configure their IDE (Intellij, NetBeans, Eclipse, whatever) with the location of the source code and the IDE will be able to extract the javadoc comments on the fly and render them as requested.
Sharing the source code also has the additional benefit that your partners can debug their (and your) code better. By themselves, javadocs are rarely sufficient for debugging complicated problems.
Alright, if everyone ever has this probelm again, here's a complete tutorial:
As #Gabe Sechan already said, the Doc is not compiled into the JAR for some valid reasons. Instead, I recommend you to add the following to your JAR:
module compilation output
content of "src" directory / alternatively: module sources
Build --> Artifacts --> All Artifacts.
Now, if you add your library JAR into a project, it will show "Classes" and "Sources" in the right tab, as IntelliJ automatically recognizes you've bundled both into the JAR.
Now, IntelliJ should show your documentation, as it lives within the source files.
If, for some reason, IntelliJ switches from its "fancy" documentation popup to unformatted plain text, proceed as follows:
Navigate to File -> Settings -> Advanced Settings, and in the 5th block, where it says "Documentation Components", just tick everything you find. That's gonna fix it.
Thanks to Gabe Sechan again, your answer helped me to understand what won't work, and finally I've found a way to make it work myself.
I heavily use the Eclipse organize imports function but a major annoyance for me is its tendency to add some incredibly niche type from a dependency with the same name as a class from the JRE.
For example, when I declare Map map; and run "organize imports", Eclipse may add import net.some.dependency.of.my.dependency.i.never.use.Map instead of import java.util.Map and then valuable time is lost as I figure out why map.entrySet() does not work anymore.
Is there some way of imposing a priority system on imports? For example:
JRE classes
My own classes
my dependencies
dependencies of my dependencies (and so on for 5.,6., ...)
I use Eclipse Neon 4.6.0M7.
P.S.: My dependencies are managed with Maven 3.3.9, in case that makes a difference.
I don't know about support for priorities, but you could simply say you are not interested in some types or packages in the preference page Java / Appearance / Type filters. Types here are not shown in content assist.
E.g. I never develop in AWT or Swing, so I turn them off for the content assist as can be seen in the screenshot
I would take a close look at the Eclipse .classpath file in the project folder. If classpath entries are ordered in some way, maybe this ordering is also controllable in the IDE option dialogs.
See What's in an Eclipse .classpath/.project file?
I'm working on a project in IBM Integration Toolkit 10.0.0.3 (formerly known as IBM Integration Bus) which is based on Eclipse. I have restructured a couple of Java libraries and part of this restructuring was to add a level in the package structure. To do this, I created a new package and moved the source files from the old package to the new. The next step is to delete the old (empty) package which has proved to be quite challenging.
It seems that the version of Eclipse that IBM Integration Toolkit is based on is quite limited.
The problems I have are:
Packages which do not contain any files are not visible in Package Explorer.
It is not possible to change this in the filter (Package Explorer -> View Menu -> Filters...).
It is not possible to delete packages which contain files, and as soon as I remove the files in the package it disappears from the Package Explorer.
If I delete the package outside of Eclipse, they don't show in Eclipse, but Eclipse still recognizes that the package exist. (I've tried creating a new package with the old name and it stops me from doing so saying that it already exists).
I've also tried installing a new version of vanilla Eclipse and deleting the packages using that, but IBM Integration Toolkit still recognizes the packages.
Does anyone have any idea of how I can remove the packages considering the limitations mentioned above? Because of 4) it leads me to believe that there is a config file somewhere which stores that there should be a package in that location. I'm thinking that I can delete the packages outside of Eclipse and then edit this config file. Is there such a file?
If anyone has an alternative way of removing the packages using Eclipse that would be even better.
A colleague found a solution. Switch to Java view and then it's possible to change the filters to show empty Java packages.
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.
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