An attempt to simplify basic modularity for Maven users

[Milen Dyankov]

Hi all,

I've been working on a PoC called Eccentric Modularity (EM) which is available here https://github.com/azzazzel/EM The basic idea is to provide a jump start into modularity (particularly in the scope of resolving dependencies and assembling applications from modules) for people not familiar with OSGi. In fact it tries to hide OSGi from the developer as much as possible.

I know we have enRoute which is great but 

 - still requires you to learn a fair bit of OSGi to use it. 

 - escaped multiline properties files full of semicolons an commas are hard for developers to understand

 - the related OSGi maven plugins need somewhat complex (for average Java developer) configuration even for the simplest cases (I know it's Maven model to be blamed here) + the above mentioned properties files.

So EM tries to work around those adoption roadblocks and provide a clean and simple (kind of JPMS type of simple) approach for the most common usecases. The idea is to bring some of the cool OSGi things (particularly Requirements and Capabilities + Resolver) to the outside world without even mentioning OSGi. In fact the first example uses Java's SPI Service Loader rather than OSGi services at runtime, just to demonstrate those tools are useful even if one don't want to go down the OSGi road.  

From code perspective it's just a (somewhat ugly) hack dynamically adding and configuring bnd maven plugins to a Maven project based on some properties. If the concept is of any interest to anyone I'd probably invest more time to learn the bnd/resolver internals and make it better. As most of you here are by far more familiar with bnd than I am, you certainly can suggest a better ways to implement it. 

So would anyone be willing to have a look, play with it and send some feedback (even if it is just "this is plain stupid idea"). 

Best,

Milen  

--

http://about.me/milen

[Peter Kriens]

I think with the current bnd defaults you do not even need a bnd file if you want to keep it simple. The default is to include the project scope and use the @Version annotation to export. Most of my project’s bnd files are quite empty nowadays. 

The escaped multiline properties files full of semicolons and commas are reserved for complex cases that are, imho, sadly inevitable if you want to use things in anger. So you will always need a bridge between starting and having the tools when the going gets rough.

Kind regards,

Peter Kriens

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Milen Dyankov]

Just to clarify I was referring to .bndrun files rather than .bnd files and the knowledge/effort required to build a runnable jar and/or to resolve dependencies.

Also I agree with "you will always need a bridge between starting and having the tools when the going gets rough". That is one of the reasons why I built this around existing bnd-*-maven-plugin(s). So moving from EM to configured per project bnd-*-maven-plugin(s) should be straightforward. 

Kind regards,

Peter Kriens

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

http://about.me/milen

[Neil Bartlett]

Hi Milen,

Thanks for the clarification, I was also confused by this as it seems bnd itself has moved quite far away from writing bnd.bnd files.

I would also like to simplify the bndrun format but I’m not sure if your approach is the right one. Perhaps some kind of pluggable transformer so the resolver can take files of any format? Transformers could also add entries that are very commonly used but don’t mean much to users, such as “-resolve.effective: active”. 

BTW I recently implemented a feature called requirement aliases, so that you can write e.g.:

-runrequires: bnd.identity; id=org.example.foo; version=‘[1.0,2.0)’

instead of:

-runrequires: osgi.identity; filter:=‘(&(osgi.identity=org.example.foo)(version>=1.0)(!(version>=2.0)))’

Of course this is only a very minor incremental improvement, not a huge revolution in usability!

Neil

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

[Milen Dyankov]

Thanks Neil,

I agree with Peter that once you go deep enough in modularity, you need to have all options available. And both bnd and enRoute are great tools. Many things can be improved of course but if one is already at that stage, it pays off learning the proper way. The EM was not meant to make things easier for people who are already familiar with OSGi and BND. Those will still need far more power than EM can ever give them.

What I'm struggling with is getting regular Java developers interested in even considering the benefits of modularity. I loose most of my listeners the moment I show them a bndrun file. I tried to use maven plugins to make things more familiar to them but then configuration can easily take 50 or even 100 lines and you still need the bndrun files. So I wanted something really simple. A SpringBoot kind of simple. Something that would demo the power without the need to understand in details how it actually works. 

Best,

Milen

  

    

[Neil Bartlett]

Hi Milen,

I get what you’re saying but what can we actually do to a bndrun file to improve it? If you boil it down to the core, it’s just a list of requirements and a pointer to an index or repository. You have to put that information somewhere, you can’t just make it go away.

Maybe we just need a friendlier format (YAML perhaps) and omit some of the noise like “-resolve.effective”?

Neil

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

[Christian Schneider]

Hi Neil,

I wonder if we could use a similar approach to karaf profiles by using bundles and Manifest headers. We could define headers that contribute to parts of the bndrun file. So such profile bundles could be provided for certain technologies that need to tweak the bndrun file. The idea is that you woud just add profile bundles for e.g. gogo, hibernate and cxf-jaxrs as required top level bundles and get a working bndrun that combines these technologies.

Such bundles could also act like karaf features by defining Require-Bundle for top level bundles that can not be determined by the resolved. So the gogo profile could provide gogo runtime, gogo jline and the gogo commands. 

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[Milen Dyankov]

Actually I was thinking of writing a YAML wrapper for BND but AFAIR this was already discussed (on this list perhaps) and someone claimed it's not so easy to do.  Also I'm not sure how much that would help. 

I actually like how EM uses special "index" artifacts that can be added much like any other dependency but bnd understands them and treats them as index. This works quite nice for Maven (not sure about other tools) and completely removes the need for pointing to an index from .bndrun file (at least for the use cases I can think of).  One can deploy "index" artifacts to maven central or to local Nexus or just build them locally. 

For the requirements (I assume you mean the initial ones) I don't know. From my perspective I'd say 99% of the time it's basically "I want to run this (the one bndrun file is in) module". In this simple case I choose to generate the bndrun file. But I'm sure many people out there have far more complex scenarios so I don't really have a good answer to that.