It should be simple...

[David Hooker]

I have a pretty simple project, which I created using pax-construct.  Here's the source structure:

|____com

| |____example

| | |____thing

| | | |____stuff

| | | | |____A.java

| | | | |____V.java

| | | |____api

| | | |____core

| | | | |____A.java

| | | | |____M.java

| | | | |____Vjava

| | | |____test

| | | | |____TestService.java

| | | |____types

| | | | |____A.java

| | | | |____AT.java

| | | | |____BA.java

| | | | |____CA.java

| | |____service

| | | |____thing

| | | | |____AService.java

| | | | |____internal

| | | | | |____AServiceImpl.java

| | | | | |____Activator.java

| | | | | |____Component.java

Now, I cannot get this bundle to work in Karaf (doesn't work in plain Felix either)

What I'm trying to get is a Manifest where the com.example.service.thing package is exported, but no matter what combination of BND file entries I use, I keep getting imports generated that it cannot resolve (and they are all imports of packages that do exist in the jar!)

I've spent all day trying to figure out why, with no directives (except the activator) in the BND file it keeps adding the com.example.stuff.test package to the imports.  With that in the imports, Karaf was not able to start the bundle.  I finally read something somewhere which told me that because my activator instantiates an object from that package, BND created the import.  So why won't Karaf resolve it?

BTW, I'm using the Maven Bundle Plugin, and the Manifest says Tool: Bnd-1.5.0

[David Hooker]

Sorry, that's Tool:Bnd-1.50.0

[Peter Kriens]

It is hard to say anything without a bnd file ... or the instruction part in the pom

It is actually quite simple, in bndtools that is.

Kind regards,

Peter Kriens

[Christopher Brind]

Have you tried using Private-Package and listing your private packages there? e.g.

Private-Package: com.example.service.thing.internal, ... other packages ...

Cheers,

Chris

[David Hooker]

I installed bndtools for Eclipse, and did some more messing around and seem to have gotten past this particular issue.

For a general comment/question: I just started trying to use OSGi a few days ago. Wow, for a platform that's supposed to provide a unified way of deploying Java components, there are so many ways to skin the cat! Equinox, Felix, Karaf… BND, Bundlor… Maven… Pax… so many tools and paths! I spent many hours just figuring out a basic process to create an OSGi project and deploy a simple bundle (and even had issues there!) because the tool chain is so complex.

And now I may have to abandon the effort completely. One of my components uses Drools - which has no readily available bundle. I found in the distribution that they have zips with all the dependencies as bundles. I deployed them (in Karaf), but then the main Drools bundle wouldn't deploy due to the "Uses constraint violation" with multiple paths to javax.xml.bind. I read your articles, Peter, on ways to solve this, but they assume Equinox and I'm using Karaf. Still looking for answers there.

So this just leaves me to wonder if OSGi is really worth this effort. I will definitely need a component architecture, but maybe this isn't the one - which is sad because I really really like it.

[Peter Kriens]

And it actually is ...

I think you're trying to use tools without having a basic understanding of the area. OSGi is no secret sauce that you can sprinkle over code and it gets better. It is also not a library that you can add to an existing code base that then adds some core functionality. It is an incredibly powerful way to provide an architecture to systems/applications. Unfortunately, it requires a way of thinking that is not common in our industry used to quick fixes. We all want to have the benefits of modularity but are not willing to invest what makes it tick. 30 years after Fred Brooks' 'The mythical man month' we're still hoping for a silver bullet.

In the last 8 months I invested significantly in learning HTML 5 (Javascript, CSS, HTML, JSON, and a large number of Javascript libraries). I thought I understood those technologies since I had been using them over the years for different projects (I even felt somewhat of an expert!). However, it is not until you build a real life application that you start to "feel" what a technology is about. Looking back at my code from the beginning I can only but cry for the messes I made. On top of this (hopefully not local) summit I can only conclude that the OSGi provides a unique way to organize large applications that is sorely lacking in all these web areas. I am pretty sure that this is not because I know OSGi so well and just miss its familiarity. It is because I can now see where things do not scale despite the many desperate attempts to struggle with modularity in the web world.

The main problem is the 'Hello World' fallacy. If it is not possible to do a 'Hello World' in 5 minutes than the technology is considered too complex. The effect is that any technology desperately adds hacks that make the 5 minute tutorial possible, even if these hacks have little to do with the core architecture. Unfortunately, OSGi requires a paradigm shift and these shifts require more than 5 minutes, even for the best. It took 15 years to go from structured programming to object oriented. I still hope to see service oriented programming become mainstream in my life time but I am sure it is happening.

So now about you're rather unfair complaint that it is all so complex. The diversity and richness is a sign of maturity and success, it shows many people and groups have adopted the technology and built upon it. In actually pales in comparison to the JEE world but that happens to be the world you know, which therefore always looks simpler. However, if you look deeper then you find that the core technology is very simple, straightforward, and surprisingly simple to use. If you fire up bndtools it actually does take less than 5 minutes to do a 'Hello World' component if you follow the flow. However, if you start at the end it is easy to get lost in the technology since Eclipse, Karaf, Virgo, Maven, Spring, Pax, and others all added their own functions, quirks and interpretations on top of OSGi. If you want to understand OSGi then start with the basics then move on to the next step since at that moment you can understand the choices you're making. Actually, follow one of Neil's courses and learn it infinitely quicker.

That said, what I have learned over the past months is that OSGi utterly lacks a skeleton (web) application/system. An 'OSGi on Wings'. Though there is a lot of code available in JEE, it invariably tends to be highly coupled and not very cohesive. It always thrills me to see how little code you need in OSGi to do pretty complex things. Since I wanted to build an OSGi system as OSGi was intended to be used I had to develop a lot of basic infrastructure since these basic components are just not available. I'd love to write a book about OSGi architecture but looking at how the 'OSGi in Action' book is pirated it seems that serious book writing has become a heavily deceased victim.

Anyway, from your mail it sounds like you're in a hurry and just want a modularity sauce. In that case, move on. OSGi is a huge pain in the ass unless you take its edicts to heart.

Kind regards,

Peter Kriens

[Paul F Fraser]

In my journey up the OSGI learning curve I have come to the conclusion that declarative services is
the way.

It would be nice to have a book/document bypassing all the earlier stuff (which confuses the issue)
and starting with DS. In a lot of the current books, DS, component factories and creation of object
instances using config manager are only a few paragraphs, if any.

Creating instances with config manager is still a bit of a blur, but examination of some examples on
Github will probably offer the answers.

I am at present fighting the problem of using Bndtooks with EGit and Github. For example, how do you
go about creating the .gitignore file in a multi project repository?

Regards

Paul Fraser

[Ferry Huberts]

On 21/12/12 12:25, Paul F Fraser wrote:
> In my journey up the OSGI learning curve I have come to the conclusion
> that declarative services is the way.
>
> It would be nice to have a book/document bypassing all the earlier
> stuff (which confuses the issue) and starting with DS. In a lot of the
> current books, DS, component factories and creation of object
> instances using config manager are only a few paragraphs, if any.
>
> Creating instances with config manager is still a bit of a blur, but
> examination of some examples on Github will probably offer the answers.
>
> I am at present fighting the problem of using Bndtooks with EGit and
> Github. For example, how do you go about creating the .gitignore file
> in a multi project repository?

- a .gitignore is directory based. It can filter the directory it is in,
and every directory 'below'
- there can be multiple .gitignore files

so no need for a single .gitignore file


--
Ferry Huberts

[Neil Bartlett]

You can have a single .gitignore file though. Mine usually looks like this:

/cnf/cache/

/*/bin/

/*/bin_test/

/*/generated/

[Paul F Fraser]

Thanks, Ferry,

In your fork of Neil Bartlett's masterclass_2011_08 their is only one .gitignore. How has this been
done?

If I create one .gitignore file in the workspace (root) outside Eclipse (the only way I have found
to create it) it does not appear in the package explorer or the navigator or seem to have any effect
on the commits.

Regards

Paul

[Ferry Huberts]

On 21/12/12 12:45, Paul F Fraser wrote:
> Thanks, Ferry,
>
> In your fork of Neil Bartlett's masterclass_2011_08 their is only one
> .gitignore. How has this been done?
>
> If I create one .gitignore file in the workspace (root) outside
> Eclipse (the only way I have found to create it) it does not appear in
> the package explorer or the navigator or seem to have any effect on
> the commits.
>
> Regards
>
> Paul

I the case you describe you just hand edit the file outside of eclipse.
I guess you can call it a shortcoming of egit to not show you those ignores.

My own style is to keep .gitignore files as local as possible (as long
as practical)

It's a matter of taste and of what works best for you.


--
Ferry Huberts

[Neil Bartlett]

While I mostly agree with Peter's reply to you David, I do also feel some sympathy.

First regarding the bewildering choice... well, I get this whenever I visit the USA. Blue cheese, thousand island, ranch, italian, french, caesar, mayo, chili mayo, lemon mayo, half fat mayo... sheesh, just give me the f***ing salad!! But you know what, I also visited the Soviet Union in the early 90s when there was NO choice at all. I know which I'd rather have.

The number of tools and libraries is a function of the maturity of the community. Yes, some of them are dead ends or have been abandoned by their authors... the commit records in their source code repos can help to determine this. Others you're just going to have to evaluate for yourself, just like you do normally with Java tooling and libraries. I can point out one thing though: the choice between Equinox, Felix and Knopflerfish is NOT one that you need to make up front, just stick with standard OSGi and your code will deploy cleanly onto all of them.

Regarding the complexity of the toolchain... well, Bndtools is ALL about removing complexity and smoothing the path to developing for OSGi. If you've tried Bndtools and followed the tutorials and you still think it's too complex, then it means I have failed, and I want to hear specifics about your experience so that I can fix it.

As for Drools, I know that it's a particular challenge in OSGi because it uses quite a few classloading tricks, including runtime classfile generation. I also know that people in the Drools community (including Drools committers working at Red Hat) have got it working satisfactorily on OSGi. I recommend that you ask about OSGi support on the Drools mailing lists. Also don't discount Peter's articles just because they talk about Equinox instead of Karaf... since OSGi is a standard, most advice carries over perfectly well. The differences tend to be just about where the configuration files live, etc.

Finally, I promise you that OSGi is worth the effort and implore you to persist with it!

Neil

[David Hooker]

Hi Peter-

Thanks for bringing me back to to Earth :-) It's my hubris combined with a week straight of 16 hour days that let to me firing off my (yes, unfair) little tantrum.

I'm not a JEE guy that was hoping to go from Hello World to a production system overnight. In fact, I'm not a JEE guy at all; I tend to build platforms myself. Starting this new project, I wanted a runtime container which had some kind of support for runtime control (shell) and provide some basic services. I have successfully steered clear of JEE and Spring over the years, but when looking into OSGi I realized that, finally, here was the "platform" I was looking for. I didn't take the time to really learn it from the ground up and get the feel for it up front, like I normally would, and just dove right in. My tirade was just the moanings of someone who was tired and under the gun.

The good new is, however, that I now have my code running across 4-5 bundles (one of which embeds Drools), one of which also implements Karaf shell commands. I feel pretty good that I was able to, in a week, hoist my components up on a technology platform that I knew nothing about when I started. It helped that my system is already "service oriented" :-) And this effort has actually proven to me that OSGi is the right choice. Now to really learn it right! I'm sure I'll be firing off questions to the list over the next few months.

Again, thanks!

-David-

[David Hooker]

Hi Neil-

I won't repeat my (just sent) response to Peter… just #include it here.

I haven't really dug into any of the tools yet - just followed some instructions on various web sites to get up and going as fast as I could.  Pax Construct seemed to the the easiest to get started, or maybe it was just the first one I got to work.  I found it before I found Bndtools.  I did run across your Bndtools page and I installed the Eclipse stuff.  Nice BND file editor!  I'm sure I'll be really digging into the tools over the next few weeks.

I knew I would like OSGi when I started looking at it, and I'm sure I like it now.  I feel like I'm learning it by crashing headfirst through a brick wall, rather than taking the time to do it right.  But hopefully things will slow down and I'll have a little time to really get to know it right.

Thanks, and I'm sure you and the list will be hearing more from me.

-David-

[Andrei Pozolotin]

Peter:

can you please help with this:

is there feature in
http://www.aqute.biz/Bnd/Bnd
or in
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
or in some other tool,

which allows to check a  set of bundles to verify if they contain package split?
http://wiki.osgi.org/wiki/Split_Packages

problem at hand: new netty v. 4 needs to convert all its maven modules into osgi bundles and they do have some split packages
https://github.com/netty/netty

Thank you,

Andrei

[Peter Kriens]

If you put all bundles on the classpath and then do Private-Package: * it should report any split packages to you:

findsplit.bnd:

-classpath: ${lsa;jar/*}

Private-Package: *

$ bnd findsplit.bnd

You probably have to parse the output since the error is, as I recall, repeated rather loudly ...

Kind regards,

Peter Kriens

[Andrei Pozolotin]

Peter

Got it; Thank you,

Andrei

[Romain Gilles]

I all,

I'm new to bnd and I'm a maven user. But as the maven plugin sound like an bridge between bnd and maven words I would like to know if there is no way to have a fail fast option on package splitting?

The default ~ behaviour - if I understand it well - merge the split packages. I would like an error option for all packages.

Is it possible?

Thanks,

Romain.

[Andrei Pozolotin]

Romain:

this is how netty is doing this check
https://github.com/netty/netty/blob/master/testsuite-osgi/testsuite-osgi-split/pom.xml

--
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/groups/opt_out.
 
 

[Romain Gilles]

Thank you Andrei,

I will test it :)

Romain