How to make available osgified jars on github as indexed repos

[peter....@openfokus.org]

I would like to make available a couple of osgi-wrapped jars (which are non-osgi conform) from various open-source projects on github.


I want to achieve the following:

- share the wrapping effort with others
- share the bundles between bnd workspaces

Concerning the second point , I am aware of this discussion https://groups.google.com/forum/#!msg/bndtools-users/Lx19OVkSApE/FI2___DnAgAJ


Questions:

1) what is the prefered naming convention for wrapped jars ? For example the jar files for the Stanford Natural Language Processing project are called like this:

stanford-corenlp-3.6.0.jar

But the wrapped bundle will contain other jars ( themselves non-osgi conform) like:

    lib/ejml-0.23.jar, \
    lib/javax.json.jar, \
    lib/joda-time.jar, \
    ...


How should the generated bundle be named ?

osgi-stanford-corenlp-3.6.0.jar ?
osgi-complete-stanford-corenlp-3.6.0.jar ?
osgi-standalone-stanford-corenlp-3.6.0.jar ?

Would it be preferable ( even if potentially more time consuming ) to first wrap each of the dependencies ?

2) How can I set up  a local directory that gets automatically indexed when the eclipse build of the wrapped jar succeeds ? This directory would need to be pushed to the repo on github to be available
in other bnd-workspaces. Should I use the replease repo for this ?

Is there as standard procedure for how to share wrapped bundles as indexed repos ?

Thanks for your suggestions

Peter Vittali

[BJ Hargrave]

Do not put osgi in front of the name. They are not from the OSGi Alliance.

Since you are supplying them, you should prefix them with your group id (e.g. org.openfokus).

See the bnd project's dist folder for an example of indexing a release repo: https://github.com/bndtools/bnd/blob/master/dist/build.gradle. We then put that output in bintray, https://dl.bintray.com/bnd/dist/, for others to use (https://github.com/bndtools/bnd/blob/master/cnf/ext/repositories.bnd#L3).

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

--

--
BJ

[BJ Hargrave]

Also look at https://github.com/bndtools/bundle-hub/blob/master/build.gradle since you will need to get the indexer jar on your gradle scripts class path. The bnd build build's that jar, so it gets it from its own workspace repo.

--

--
BJ

[Christian Schneider]

I propose to put such builds into servicemix bundles. It already hosts a big number of such bundles and has a community that can help in continuing the effort for new releases. See https://github.com/apache/servicemix-bundles

I think publishing an index is not really necessary anymore for most cases. The indexer plugin as well as the new pom based index that Peter writes will allow people to index anything in a maven repository on the fly. The published index is not so valuable as it only has http urls which do not work well in environments were jars are only available thorugh a nexus proxy. 

So if the bundle is kind of standalone you are fine by plublishing it in maven central. If you need several bundles that only make sense together then just publish a pom with the dependencies to make it even simpler. I already started this for aries rsa, aries jpa and cxf dosgi and it works great for bndtools. It also works nicely in company environments as you can have a maven based proxy to download all dependencies.

Christian

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

--

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

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

[Achim Nierbeck]

Just to complete the picture, there is also the PaxTipi[1] project available for such use-cases :-)

regards, Achim 

[1] - https://ops4j1.jira.com/wiki/display/PAXTIPI

Apache Member

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
blog <http://notizblog.nierbeck.de/>

Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master 

[peter....@openfokus.org]

Thanks to everybody for your advice. So it seems that there are at least 3 alternative solutions ( (-; ) for sharing osgi bundles and make them available for the automatic bundle resolving process.
I certainly need some time to figure out what works best for me, and I hope to be able to come up with a simple step-by-step procedure for other non-osgi experts .

I'll be back ..
Peter Vittali

[peter....@openfokus.org]

The servicemix bundle repo seems to be indeed the place where such bundles would fit in.

Concerning  maven/pom: since switching to bnd/osgi I haven't used poms anymore, with bnd I suppose that these poms are generated rather than written by hand. Is this correct ?
Is the plan then to have all osgi bundles on central rather than on bndhub ? Woud the servicemix repo you mentioned ultimately be part of maven central ?

And another question: I have experienced troubles when resolving against the bndhub bundles set. With some 40 bundles in my local repo, the resolving process would suddenly start to take very long ( 1 minute )
and I was obliged to download a subset of the bndhub bundles to LocalRepo and sever the link to the bndhub repo on github in order to keep the resolving process fast.
So I am afraid that if I make servicemix-bundles a remote repository , the resolving process will again be too slow. Did I misconfigure ? What is your experience ?