decebals

For context, the guidelines are split into standalone markdown files (one for the model, one human-readable README per topic).

I'm the creator of PF4J (https://github.com/pf4j/pf4j) - a plugin framework for adding extensibility to Java applications, used by companies worldwide (https://github.com/pf4j/pf4j#trusted-by).

After years of GitHub discussions, I kept seeing three recurring patterns everyone rebuilds:

1. Service injection - custom PluginFactory boilerplate to wire platform services (Issue #319 is typical: https://github.com/pf4j/pf4j/issues/319)

2. Plugin communication - everyone builds their own EventBus

3. Configuration - no standard approach for plugin-scoped settings

Hit these myself building a JavaFX app. PF4J handled loading, but then 30+ lines of factory code just to inject services.

Built pf4j-plus to standardize this layer:

BEFORE - custom factory everywhere:

    public class MyPluginFactory extends DefaultPluginFactory {
        @Override
        public Plugin create(PluginWrapper wrapper) {
            Plugin plugin = super.create(wrapper);
            if (plugin instanceof MyPlugin) {
                ((MyPlugin) plugin).setGreetingService(App.getGreetingService());
                ((MyPlugin) plugin).setEventBus(App.getEventBus());
            }
            return plugin;
        }
    }

AFTER - declare once:

    PluginManager pm = PlusPluginManagerBuilder.create()
        .serviceRegistry(r -> {
            r.register(GreetingService.class, new DefaultGreetingService());
            r.register(EventBus.class, new DefaultEventBus());
        })
        .build();

Plugins get ServiceRegistryAware, extensions use @Inject.

What it provides:

- ServiceRegistry - shared services for plugins

- EventBus - decoupled communication

- ConfigService - plugin-scoped configuration

Not a DI container replacement. Just standardizes the platform layer you'd build anyway. Especially useful outside Spring (desktop apps, CLI tools, embedded systems).

Early stage - using it in my own projects. Looking for feedback on what platform services are missing.

Repo: https://github.com/pf4j/pf4j-plus

Blog post: https://dev.to/decebals/why-i-built-pf4j-plus-1hl1

Maybe an answer is https://www.reddit.com/r/java/comments/3x1wsm/why_are_java_w...

The Pippo goal is to simplify the web development in Java (as much as possible). If you want to write a medium, big application in Java you have a lot of options, standard or non standard (Jsf, Wicket, Play, Spring Boot, ...). Pippo is for small and medium applications, maybe for applications where the backend is Java and the frontend is Angular or other javascript framework, for applications micro services oriented. Pippo has a clear niche and do not try to compete with the Jaava web frameworks enumerated above.

Thanks for your appreciation. With Pippo you can see your web application as a regular Java application (with a static main method).

You are not forced to create a web.xml file. Of course you can use the standard approach with web.xml but this is complete optional.

For more information please read http://www.pippo.ro/dev/quickstart.html

The idea with Pippo is that you can create easy a very custom stack. You can work with your favorite servlet container, template engine, json/xml libraries and this is great (for example I use Undertow as servlet container and Pebble as template engine). To do this is simple to add the right Pippo module in your pom.xml file and it's done (pippo-undertow, pippo-pebble in my case). I don't want to force you to work with my personal stack.

I am the initiator of this project. It's an honor for Pippo to be mentioned on ycombinator.

I see some debates related to "micro" definition. A while ago a friend of mine posted some comments on reddit justifying why Pippo is "micro". If you are interested to find out the arguments please read https://www.reddit.com/r/java/comments/3x1wsm/why_are_java_w....

When I published the first article about Pippo on Dzone(about one year ago), someone asked me "what are the key differences/advantages of Pippo compared to another Java micro framework Spark?" You can see my answer in the comment section of the article (https://dzone.com/articles/pippo-micro-java-web-framework) Pippo is small, modular but it's not a simple toy. You have a lot of features that are not available in other (Java) micro frameworks.

If you want more features (security, scheduler, rest doc, event bus, mailer, DI), try Fathom (http://fathom.gitblit.com). Fathom is a Undertow+Guice+Guava+Config+Logback stack over Pippo. For people that like the super declarative approach (via Java annotations) from Spring Boot, we will try to upstream the fathom-rest module (http://fathom.gitblit.com/rest) in the pippo-controller module.

There are some new features/modules that are not documented yet (for example PippoTest class from pippo-test module, ...) but Pippo demos (https://github.com/decebals/pippo-demo) are great and you can learn incrementally many aspects of Pippo from these.

Have fun!

I don't know many things about Spark, so I can't make a full comparison. I will try bellow to enumerate some advantages of Pippo:

- modular [1] (spark uses a giant static singleton architecture)

- support (via modules) for many Template Engines [2] (Freemarker, Jade, Groovy, Trimou, Pebble)

- support (via modules) for many Servers [3] (Jetty, Undertow, TJWS); spark depends on Jetty

- directly serving of static resources [4], support for WebJar

- content type negotiation

- custom session [5] (support for cookie based implementation)

- support (via modules) for many ContentTypeEngines [6] (Plain text, Json - Gson/Fastjson, Xml - Jaxb/Xstream, Yaml - SnakeYaml)

- i18n [7] (in java or directly in template)

- support (via modules) for many IoC [8] (Guice, Spring)

- support metrics [9] (via modules - Ganglia, Graphite, InfluxDB, Librato)

- custom (template) error pages

- regex routes

Unfortunately the actual documentation of Pippo it's a little bit behind of the implementation (from documentation are missing some nice concepts: named routes, finally filters, custom route context, ...) and from this reason I cannot give you more useful links but I will fix this aspect asap.

Another difference in Pippo to other (micro) java web framework (spark, ninja) is that a RouteHandler it's a real endpoint (the handle method return void). You can finalize/commit the response using send, render, redirect. Everything is transparent.

[1] http://www.pippo.ro/doc/modularity.html

[2] http://www.pippo.ro/doc/templates.html

[3] http://www.pippo.ro/doc/server.html

[4] http://www.pippo.ro/doc/static-files.html

[5] http://www.pippo.ro/doc/session.html

[6] http://www.pippo.ro/doc/content-types.html

[7] http://www.pippo.ro/doc/internationalization.html

[8] http://www.pippo.ro/mod/spring.html

[9] http://www.pippo.ro/mod/metrics.html