search

USCDataScience / sparkler

Spark-Crawler: Apache Nutch-like crawler that runs on Apache Spark.
http://irds.usc.edu/sparkler/
Apache License 2.0
411 stars 143 forks source link

Replace OSGI and Felix with pf4j #127

Closed thammegowda closed 6 years ago

thammegowda commented 6 years ago

Issue Description

We have faced enough issues with Felix and OSGI. The most awesome PR #110 is left unmerged because of the OSGI class loader issue. The learning curve is steep for Felix (We have our felix expert inactive for a while). Lets put this to an end - get rid off all xmls and configs (use convention over configuration)

pf4j seems like a better fit. So lets swap felix with pf4j and then make way to merge #110.

lostiniceland commented 6 years ago

Why not have a look at OSGi Declarative Services.

You cant get rid of (probably all) your Activators in the project. The annotations provided by DS are only build-time (yes they produce xml, but no developer has to care about them) and it is as easy as CDI in JavaEE (just more powerfull). Another nice benefit, you dont force any constraints on the plugins except OSGi itself. You can cleanup your code without affecting any existing plugin.

Oh and by the way: get rid of the maven-bundle-plugin. Use the new bnd-maven-plugin.

There have been tremendous improvements to the tooling the last two years which makes OSGi a real pleasure to work with

thammegowda commented 6 years ago

Thanks. I will have a look at the Declarative Services. Seems like a good one.

The first major issue with maven-bundle-plugin is that it replaces Maven’s default plugin for JAR generation (the maven-jar-plugin). This means that it must use a different packaging type – “bundle” instead of “jar” – and must use the extensions=true setting to override Maven’s default lifecycle. As a result, the output artifacts are harder to consume in ordinary non-OSGi projects. Therefore, many Maven developers either don’t bother to release OSGi bundles at all because of the hassle, or they release both a “plain JAR” and a separate OSGi bundle. This is deeply frustrating because OSGi bundles already are plain JARs!… they can be used unalterered in non-OSGi applications.

Woah, someone explained my pain precisely. Thanks again.