I'm working on a semantic-web project and I'm looking for real-life ontologies to test a couple of applications an algorithms. What I'm searching for are different sizes and structures, something that will allow me to benchmark the company's solutions, preferably, not home-made mocks, but something that is actually used. Unfortunately, looking at the entire ontology using OntoGraf is a little cumbersome.
I found a Protégé plugin called NavigOwl, which seems to be perfect for the task of viewing an entire ontology at once and judging its general complication and structure. The thing is, I can't get it to work.
I download the plugin from HERE and follow the instructions.
I put the jar in the plugin directory of my Protégé install.
I open protege and load an ontology
I go to Window>Tabs and select NavigOwl
A NavigOwl tab appears but it only contains the class hierarchy view, while the rest of the window is grey. It's simply blank, as shown below:
Clicking any of the classes in the hierarchy view does not change anything.
I googled for a solution and I managed to find this thread on nabble.com. The poster says he fixed the problem but he doesn't know how. Resetting the tab to default state is among the implied solutions but it doesn't work for me. Closing and reopening the tab, as well as Protégé itself changes nothing.
Have you encountered the problem? What could be the cause?
I'm using Protégé 4.1.0 Build 239 with the bundled JRE (1.5.0) on Windows 7 home premium x64.
I've tried both the JAR available here (NavigOwl plugin for Protégé 4.1) and the one mentioned in Protégé wiki at Stanford, here (version 1.1.0) but the situation persists.
I had came across the same problem but when i upgraded the JDK it started working. though i do not propose upgrading was the solution but it is working now.
Related
I'm using Netbeans IDE. It's quite annoying and it's a cause of errors the import of Java packages and/or classes that are not provided by Codename One. (Codename One use its own implementation of a subset of Java8 and it cannot support the full Java API).
For example, sometimes Netbeans imports automatically wrong packages (such as "java.awt.BorderLayout" instead of "com.codename1.ui.layouts.BorderLayout"), other times it shows me methods and Javadocs that are not available in Codename One.
Is it possible to force Netbeans to show me only packages, classes, methods and javadocs that are supported by Codename One? It could be useful to avoid errors.
We'd love to but unfortunately the only way NetBeans allows you to do that is if you build your own Java language package. That's what some other plugins like NBAndroid did AFAIK but when we implemented the plugin we didn't want to create something too complex.
If NetBeans supported a "bootclasspath" option for the JDK it would have solved everything. It does have support for plugging in an alternative JDK which can be a micro-profile but because we don't comply with the micro-profile spec I'm not sure if that will work.
At times, NetBeans suggests to import more than one package from the drop-down list. When you check carefully before pressing ENTER this might avoid importing the wrong package.
I use NetBeans for quite a while with CN1 and faced the same problem at the beginning.
I started using the Play Framework a couple weeks ago.
Everything works quite fine, I can compile, use autocompletion in Java files and SBT is running ok,
But one thing that bugs me out is that I have no coloration nor completion in the routes, and scala.html files.
I thought this was normal, but this morning I saw this page where the templates are clearly completion supported.
For me, only simple HTML tags are colored.
I checked the requirements page, and I do have the scala plugin installed. I tried to uninstall/reinstall without success.
I use Play 2.4.4 and IntelliJ community edition 14.1.4.
I looked for a solution on the internet, but nothing so far.
Anything I could have missed? I seems like everything should just work from the Play page and intellij websites. . .
I have been using eclipse before, so my IntelliJ installation is pretty clean.
Thanks!
Both of your links about using the Play Framework with IntelliJ seem to miss the point that you need the Ultimate Edition of IntelliJ in order to get the full support. See the comparison Matrix where Play support (for version 1.x and 2.x) is listed as "Supported only in Ultimate Edition": IntelliJ IDEA Editions Comparison.
The current support, which you've noticed, is plain Java and as it seems XML, since HTML is also an "Ultimate Feature".
You may want to try the free 30-day trial of the Ultimate Edition to see if it works for you - including the Play support - and if it's worth buying it.
Is there any way to discover programatically (but not in PDE code) which eclipse projects are opened?
I was hoping that would exist a .metadata anywhere telling me that, but couldn't find any non binary data.
The closer I got was something like:
"$WORKSPACE.metadata/.plugins/org.eclipse.core.resources/.projects/%s/org.eclipse.jdt.core/state.dat" where %s refers to the project name
I think m2eclipse uses that guy for some kind of control, because on a m2project this file gets removed as soon as the projects build.
Also, i found some information on .metadata/.plugins/org.eclipse.ui.workbench/workingsets.xml but none of them give me the full info I was hoping to find.
Does anyone knows how to solve it?
I was trying on eclipse 3.7.
On eclipse 4.3 , at least, its possible to parse $WORKSPACE/.metadata/.plugins/org.eclipse.ui.workbench/workingsets.xml and look up whether the desired project has a factoryID="org.eclipse.jdt.ui.PersistableJavaElementFactory", meaning it is opened.
I Didn't try this on 4.2 tough, maybe it works there as well.
To do it "programmatically", you call the APIs from the org.eclipse.core.resources plug-in. Otherwise, you are doing it wrong.
I've been searching for a long time now to find a decent IDE for Scala.
Eclipse is not satisfying at all, as auto completion doesn't work, somehow. Also, I can't modify the libraries at all in the build path e.g. set the docs/source.
IntelliJ seems better, however, there are some major bugs:
When the drop down menu appears that lists all the function, some of them are sometimes just not shown! I think it's because of scala-library / scala-compiler, it mixes them up or something...
The docs cannot be fetched, I get this message over and over again (here the functions are listed, strange enough...):
This is the library window:
The dependencies and the compiler are set right, I strongly suppose.
Does anyone know what the problem is? And how to fix it? Or is it a known bug?
Is there an IDE that can handle Scala?
Regards!
Typically, searching for names (values/classes/functions/etc.) for auto-complete can be quite slow compared to Java in IntelliJ simply because the automatically imported namespace can be quite large, and it also searches through all implicit conversions. However, I've never seen it refuse to show functions like your screenshot, what version of IntelliJ and Scala plugin are you using?
I've never gotten the pop-up docs to work via attaching JavaDocs (I haven't tried remote fetching), so I'd recommend just ctrl+click to go through to the source to read the documentation there. (However, the function/type definition does popup correctly when sources are attached). I'd suggest posting an issue at http://youtrack.jetbrains.com/issues/SCL if you have the opportunity.
To your final question, the answer is unfortunately no. The tooling for Scala is nowhere near that of Java, but both Scala IDE for Eclipse and IntelliJ are making great progress in changing that, and both are strong in some areas while weak in others. In the end, you'll get limited support either way, so choose whichever fits you best.
I have found the solution to the problem:
The bug was caused by Java Decompiler Plugin. It tried to decompile the binaries of Scala's class-files, which obviously failed. This led to that error message and further led to the Scala plugin not working as it should, thus not displaying some of the functions.
This took me a long time to figure out, I installed 2 other versions of IntelliJ (which apparently imported the JD plugin), NetBeans and downloaded several builds of the Scala Plugin, only to discover this cause. Deactivating Java Decompiler solved it.
Regards.
Simple usecase: assemble an Eclipse product using simple scripts, just dumping bundles into the plugins dir.
This used to work with 3.3 - with 3.5 it's broken: my application doesn't start as the app plugin is not found.
Question: what's the easiest way to fix that? This seems to be the only pain in the whole upgrade process for me.
Attempts:
I guess this is a no-no for P2: it maintains the bundles.info file instead, which is probably very smart.. a bit too smart for me.
Some ideas I had:
can I just skip P2 altogether and get back to plain old, simple -dirty- discovery mechanism?
can I set up plugins dir as a 'watched directory'
looks like I need to use the p2.reconciler for that.. oh wait, it's deprecated already :-( bug 251561.. (thanks VonC for the pointer)
can this old setting in the config.ini still work? (which is now replaced with the 'simpleconfigurator') osgi.bundles=org.eclipse.equinox.common#2:start, org.eclipse.update.configurator#3:start, org.eclipse.core.runtime#start
should I call the (p2) director?
"please pick my plugins up" :)
I'd avoid the dropin folder for this - that's more for the
end-users.
I'd avoid messing with the bundles.info if possible.
I don't care about all those smart features in my product yet- actually the users don't use the built-in update mechanism at all.
So I'd like to KISS (ie: just to start up), and add more advanced support when needed.
I've asked this on Eclipse forums, but no answer yet, so would really be grateful for some enlightenment.
Also, feel free to correct me on the assumptions - I've just read the P2 docs, which seem confusing at times.
Thanks!
Answer: actually option 3 above seems to work after all - thanks Francis for confirming this! (it didn't work originally, but that was probably caused by some missing deps).
My only issue with that now is, some Eclipse bundles actually require simpleconfigurator. So I wonder if swapping it out will cause problems down the line.
You can alter your configuration/config.ini file to not use the org.eclipse.equinox.simpleconfigurator (which does the p2-based configuration) and instead use the org.eclipse.update.configurator which is the old-school way of just configuring whatever is in the plugins directory. This should give you what you want.
Even if it does not fully answer what you are after, you can specify in an eclipse.ini (like the one I describe here):
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:/jv/eclipse/mydropins
That does specify to p2 to monitor any directory of your choosing to detect plugins in it.
Another source of idea could be this article: Composing and updating custom Eclipse distros
It's not hard to create a feature based product that includes these things, and do a product build to end up with something like this:
Note: the concept of reconciliation is detailed in the eclipse Wiki.
For certain installations of Eclipse, there will exist the notion of a shared installation -- this may be in the case of a Linux system where a base set of software is installed via packages (perhaps RPMs), or may be in a Maya deployment where shared profiles are defined in a central server.
In both cases, it is necessary to perform reconciliation between the shared profile and the user's current instantiation of the profile including any modifications they may have made.
Part of this mechanism is the Dropins Reconciler setting. Although, as bug 251561 illustrates, it is not advised to put too many plugins in there.
Maybe this will help you (shot in the dark)? I found this when upgrading my Eclipse installation to Galileo and trying to keep my Flex Plugin install.