setting a local index.xml file in bnd.bnd

[David Daniel]

In my bnd file I have 

-standalone: \

    ../indexer-pom/enroute/index.xml,\

    ../indexer-pom/target/index.xml.gz

    

-plugin.6.Enroute: \

        aQute.bnd.deployer.repository.LocalIndexedRepo; \

            name                =       Local ; \

            pretty              =       true ; \

            local               =       ${project.dir}/../indexer-pom/enroute/index.xml

       

-plugin.9.Maven: \

\

        aQute.bnd.deployer.repository.LocalIndexedRepo; \

            name                =       Release ; \

            pretty              =       true ; \

            local               =       ${project.dir}/../indexer-pom/target/index.xml.gz

The standalone part works with the run tab when looking at it in eclipse but I cannot seem to get the build tabt to see either of my indexes.  I am getting an error that says "Error querying repository configuration"

[Neil Bartlett]

Hi David,

The standalone mode is intended for resolving and running in the absence of a bnd workspace, so I’m glad to hear that it works. However it is NOT intended for providing build dependencies. Maybe we missed something here… but our primary purpose in adding standalone mode was to support users who want to build with another tool (e.g. Maven) but still want to use the resolving and running features of Bndtools.

If you are building with bnd, then why not create a workspace with a cnf in the traditional way? Just trying to understand your use case to see whether we need to extend standalone into build dependencies.

Regards,

Neil

--
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.

[David Daniel]

I am pretty sure that I am using it the wrong way and should be thinking about it another way as I am completely new to bndtools.  My current environment looks like the following.

We have a artifactory server that hosts all the current bundles.

I am using karaf so the features.xml files pull the bundles from artifactory that are needed into my osgi container

My maven file pulls in the dependencies from artifactory into the ide environment

I am using the maven-bundle-plugin to build my bundles

I am using the karaf-assembly plugin to build my custom distribution

I am using pax-exam for testing

 

Where I have had issues is in debugging.  I can remotely debug and run surefire from maven for unit tests but I can not run from the ide and step into things.  I probably got my maven dependencies wrong somewhere.

I would like to try out submodules and enroute as they seem more standard than karaf (I am still a big fan of karaf but I would like to make sure I understand my choices) but our build system is based around maven and I don't want to change that as it effects jenkins sonar and other tools that we use.

I like the ideas behind the bnd-maven-plugin and would like to switch to that but it requires a bnd file.

I am not against having a cnf project but I would greatly prefer to only manage the dependencies in one place which I was hoping could be the pom.  If I have to maintain in two places like I do with the features.xml and pom I can but it causes issues with dependencies getting mismatched like I have run into before.

I am guessing what I can do is have a cnf project for local building and use the bnd-maven-plugin for building in jenkins and then use the bnd-index-plugin to generate the index.html file that the cnf project references.  Is this how I should be looking at things.  I am really just getting started here with bndtools and am really flexible with how I do things.  I just don't know the right way to do things.

Thanks for all your help and support,  (Even on a Sunday, I was not expecting a response)

[Tim Ward]

Hi David,

It sounds like what you really need is a maven plugin that will run bnd-style integration tests from your standalone bndrun files. Bndtools would then let you launch those in Eclipse in the standard "Run as..." way.

No such plugin exists, but I'd support the creation of one if you want to get the ball rolling with it.

As for having a separate cnf, I would suggest that it's probably not a good way to go. Either Maven, or the Bnd workspace needs to be in control, not both. That means sacrificing some bndtools features if you want to keep using Maven as your build tool (at least for now). We do eventually want to get to feature parity with Maven builds, but unless we get investment from a company it's likely to be several releases before we get there.

Also, kudos for being at the bleeding edge with this. We only started to work on this Maven support a month ago, and it looks like it's already starting to give you some value!

Tim

Sent from my iPhone

[David Daniel]

It has.  Everyone in the OSGI community has been great and they are all so good at what they do.  I know I will not be able to get funding but I will do what I can to contribute.

Thank you for your time,

  David Daniel

[Christian Schneider]

What would be needed to make the m2e incremental build as good as the bndtools build?

I think the main problem currently is that the maven-bundle-plugin does not participate in the incremental build. Imagine we would get that working, what would we then still be missing?

Christian

[David Daniel]

I think Neil did a pretty good job explaining some downsides here http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html but I think both toolsets are great.  I was just greedy and trying to get the best of both worlds.

[David Daniel]

I should have elaborated more.  For me the the inconvenient part is having to have a bundle pom type.  Not all of our company uses osgi.  I spend some time going though our other libraries and wrapping them but it would be nice if I could add something to our top level poms so I did not have to have two projects for each library of others that I want to use.  Also when I wrap stuff I can only have one name in artifactory so I have to take there normal artificat name and put an -osgi after it to not have conflicts.  Not a big issue.  Just inconvenient.

[Tim Ward]

As already stated, the fact that the maven-bundle-plugin does the full packaging of the jar is bad for incremental build (rebuilding a jar as you save the file). It also does other bad things from a user perspective (a non jar packaging type), and encourages people to write bad bundles (export by default).

From a bndtools perspective we're missing the ability to read from/publish to Maven repos. Peter is working on this for 3.1.

From a Maven perspective you lose support for bnd integration tests, base lining, and error markers/quick fixes for things (bnd bundle configuration, ds annotations, base lining errors). 

Supporting this is a big job. We need to make bndtools support a workspace-less model, and then collect reporting information from the M2E build.

Tim

Sent from my iPhone

[Christian Schneider]

Hi David,

yes the wrapping of non OSGi jars is always a big problem. Luckily many projects already provide bundles natively now. You should also check the servicemix bundles. Many third party libs are provided there. So for most of the projects I did recently I just needed to wrap a handful of jars myself.

Thanks for the link to Neil´s blog entry. I already read it some time before but hoped the changes would already have gone into the original maven bundle plugin. I will ask on the felix list what the plans are for this and maybe help if I can.

Christian

[David Daniel]

Yes I use a number of servicemix bundles.  I actually started with servicemix and dropped down to karaf.  I have read many of your blog posts and appreciate all that you have done.  I do hope that all the projects work together because I have seen some good ideas from each.  Thank you for all your hard work.

David