Dear Stefane, all, thanks for your comments and welcome. Some replies in-line ;-)
Am 23.07.2011 um 20:36 schrieb Stefane Fermigier: > > >> Difficulties I see at the moment (just to mention these...): >> - technological issue: LMF is currently not using OSGi, but it uses a Gradle >> build system, > > OSGi is not a build system (ok, there is a build system specific to OSGi, > called BND, and maybe that's what people who are really committed to OSGi > should be using - but that's another story). Sorry, I expressed myself not clearly. I know that OSGi is not a build system, the "but" should have been more like an "and". ;-) > > Stanbol uses Maven. I don't think there is anything fundamentally wrong with > Gradle (and there are many things that are wrong with Maven, but that's also > another story), but Maven is pretty much the standard, and it makes sense to > migrate the LMF build system to Maven. The main reason for us to take Gradle was that I was fed up with build systems that try to do simple things in complicated XML files. We are all software engineers, why not also write a build file in code? And Gradle offers this functionality very nicely. But of course we would switch to Maven. It is just that OSGi and Maven are the two main hurdles for us to take, because we are not very experienced in either. And we would need your help there :-) > > Apparently, there's a plugin for that, so that shouldn't be too much work: > > http://www.gradle.org/maven_plugin.html > >> Java 6 EE dependency injection (CDI) and a typical Java EE architecture >> which is incompatible with OSGi for now; > > Yes, this is probably more intrusive. > >> one of our selling points is also "easy setup" and "lightweight", so I would >> not really like to change this for a complicated architecture ... > > Some people would argue that there isn't much that's not "lightweight" with > OSGi (OSGi services are just POJOs), and I don't think OSGi (for the part > we're using in Stanbol at least), is more "complicated" that CDI. They > probably should not be seen as competing, but as complementary approaches, > and actually using DI with OSGi services is something that's already covered > with SCR or iPOJO. Yes, I think this is just our lack of experience with the technology and my rather bad experience with large frameworks (like Seam) in KiWi. We wanted to have an architecture were basically every Java developer could jump in without too much framework knowledge. On the other hand I can very well see the advantages of an OSGi architecture, and if we can get some initial help I am pretty sure that we will quickly be quite fast in it. > I don't have experience mixing CDI and OSGi, though (and that's something > that could be useful for Nuxeo, so we're willing to investigate). Googling > for "OSGi+CDI" gives some interesting links: > > http://blogs.oracle.com/sivakumart/entry/typesafe_injection_of_dynamic_osgi > http://mathieuancelin.github.com/weld-osgi/ > > So it's definitively something people are wanting to do. Yes, and probably it is not too hard to achieve. The only major issue right now is that OSGi separates classpaths while CDI scans the classpath for services to register in JNDI when it starts up. As long as we only use injection inside a single OSGi module, there is probably not such a big issue. > >> - license issue: LMF might still use libraries that are released under >> incompatible licenses, so this needs to be checked. In particular, Hibernate >> is still licensed under LGPL, and it is one of the core libraries of the >> LMF; porting to other persistence frameworks might require a lot of effort > > I don't know what's the ASF view on Hibernate. What are the alternatives ? > EclipseLink is a viable alternative, I think, but it's licensed under the > EPL. Does the ASF have a JPA project that's mature enough to replace > Hibernate (OpenJPA ?) ? I never worked with OpenJPA, but it might be an alternative. In most parts, the persistence of the LMF is more or less separated from the logic anyways, and we could even write our own persistence layer (I actually considered this out of performance reasons, because Hibernate introduces a huge overhead). The most difficult part could be rewriting queries we are using, because HQL is more expressive than JPQL. But I think it is doable. Greetings, Sebastian -- | Dr. Sebastian Schaffert [email protected] | Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at | Head of Knowledge and Media Technologies Group +43 662 2288 423 | Jakob-Haringer Strasse 5/II | A-5020 Salzburg
