@carlw I long for the kind of sanity that just gets you 8 keyboards...

And keycaps really don't count.

...cases wear out

@ron

cellFragment

support for DataGrid is committed

@amanda.hinchman-dominguez commented on @edvin’s file : I've seen this keyboard before! A friend of mine got another type but I hear these make you type way faster

I saw that tornadofx possesses OSGI drag-and-drop capabilities. Should I try create a configuration and add an app to the OSGIConsole.kt in tornadofx local library itself?

I was thinking about creating a GUI with drag-and-drop capabilities with Swing, but OSGI might be just what I'm looking for

@amanda.hinchman-dominguez In my experience, I type about the same speed as before, but it's much more comfortable. I might end up typing a little faster once I get to know it even better, but it takes time to get rid of 20 years+ of muscle memory 🙂

@amanda.hinchman-dominguez OSGi is not easy. Make sure that's really what you need.

It's only easy on paper 🙂

I see - I can see what the OSGIConsole does in a local run and decide from there!

Yeah. There is also some quick start templates to get you up and running. Be sure to watch my OSGi videos 🙂

the concept of OSGi itself is not that hard

it's just there is almost no usefull documentation and IDE support is almost non existing

and testing is also a pain

@kristofdho Exactly. The tools are in disarray. Why do they have five different maven plugins to talk to bndtools, and none of them are completed/up to spec?! Grr..

@edvin what do you think Java 9 modules mean for OSGI? is it going to be even more of a niche product?

@edvin when can we expect the IDEA plugin release? Sorry to bother you with this.

@anidotnet I will release the plugin tonight 🙂

@carlw No, I think it means very little for OSGi. The promise of OSGi is a dynamic environment, and that's completely out of scope for Java 9 modules. If you need the dynamic pieces of it, Java 9 modules can't help you. If you just used OSGi to modularize your application in the past, you can get rid of the overhead of the OSGi container if you go with Java 9 modules, but that's probably not why most people are using it IMO.

i think so too

but if you take something like apache karaf, there's going to be duplication of the export/import definitions (one for osgi and one for java 9 modules)

You shouldn't even include a module-info.java in your OSGi modules, it won't even be read, since it will be the OSGi classloader that loads them.

What might be cool though, is to support dynamic modularity using information from module-info.java 🙂 I think somebody will create such a system before long.

Maybe some kind of directive that bases Export-Package on the Java 9 stuff?

I won't even think more about this, I'll get off track.. hehe

@edvin superb news. BTW what do you think about component.javaClass.getResourceAsStream vs ClassLoader.getSystemClassLoader().getResourceAsStream as I mentioned earlier?

@kristofdho @edvin @carlw I see, I thought it looked great because of the lack of verbose object creation, but I'll definitely read into it and find people's opinions on limitations with the product before I play around with it

Huh.. I post stuff, but it doesn't show up..

Of course that one did 🙂 Anindya: I was trying to write that we can't know that the system classloader knows bout the class, can we?