Is jquantlib still using git or bazaar?

Hello Chris,

The official source repository for JQuanLib is Launchpad.
We eventually take a cut of it and mirror onto Github.

Notice that JQuantLib is slowly ressurecting from ashes, after a long period dormant.
You observation about SBT is part of that: the current trunk (or master) branch of JQuantLib is now built by SBT.

Thanks for your feedback.

I hope it helps

-- Richard Gomes

Thanks Richard! When I tried to build and install it to my local maven repo via 'sbt publishM2', it gave a lot of javadoc error.

I can help fix these issues but I currently don't have time to get up to speed with bzr in order to help. Is the long-term plan to keep jquantlib on launchpad or is there a plan to use github in the future?

Thanks
Chris

There are too much javadoc errors to be corrected at the moment.
It's much easier to simply tell that javadoc errors should be ignored and should not impact the build.

I guess that this can be done like this:

   javacOptions in (Compile,doc) ++= Seq("-Xdoclint:none", "-notimestamp", "-linksource")

The incantation is: -Xdoclint:none

Regarding migration to Github:

I do not oppose this idea. But I do not have time and I do not have enough drive to do this task at this point. The biggest problem consists basically on importing the list of bugs from Launchpad, or maybe selectively picking those bugs which make sense to be migrated and simply forget the rest.

Also, migrating to Github implies that I will be pushed to merge push requests. I will be in the critical path of progression of JQuantLib since I do not have time for doing such task.

I accept suggestions. And appreciate contributions from volunteers ;-)

Cheers

I may be able to help make the migration to github happen. However, I'm knee deep into a project right now. It may be a while before I could spend time doing that.

Although I'm capable of doing a lot of technical software work as a software development professional, I'm just a beginner in quantitative finance math. I personally find the C++ quantlib to be quite a impedance mismatch with Java. Since I'm using Clojure and Scala, I'm actually more interested in developing a more Clojure and Scala idiomatic library on top of jquantlib. That may be the areas that's worth more investment in time (personally). You're using Scala, right? Are you finding quantlib's library/API design to be quite clunky to use in Scala? Do you wish you could write more idiomatic Scala code with jquantlib?

Hi Chris,

Good to hear that in future you will be able to help.
I would like to see JQuantLib active again with more people supporting it.

Regarding Scala: Yes, I'm using only Scala at the moment.

To be honest and very realistic about JQuantLib, it would be much more beneficial if we had invested time and effort writing a wrapper to QuantLib/C++ in Scala. But Scala was very incipient 7-8 years ago and I opted for going ahead with an implementation in Java.

I thing the correct approach is a wrapper written in Scala, so that QuantLib guys focus on the quant stuff whilst others focus on wrappers to other languages.

There are technical aspects that would take me 100 lines to describe them all but, in a nutshell, Scala is a much powerful language and far more capable and suitable to the job of wrapping QuantLib.

If SQuantLib (in Scala) takes off from this brief conversation, it would be a death sentence to JQuantLib, since Java applications would be able to interface with SQuantLib easily.

Maybe a brand new project in Github?
I already own the domain squantlib.org since 2007. :-)

Cheers

By wrapping, you meant SWIG/JNI to the C++ quantlib library? I'm not a big fan of that for performance reason and not-as-easy deployment of the jar and platform shared libraries etc. It's quite a pain.

My thinking was more in the line of implementing common code in JVM language (Scala/Clojure) and have separate idiomatic layer for each language.

And I agree on separating the concerns of writing "quant" functions so that it's easy for quant to implement the math stuff.

That said, I'm still new to quantlib and the whole quant library area. I'm sure I'd change my view over time. :-)

Yes, why bother porting jquantlib over to github when we can just start over. It's just not worth migrating historic artifacts over from launchpad. I don't see any value in doing that.

Chris

Historically, I was responsible for ~50% of the code you see in JQuantLib.
When I stopped working on it, the development stalled.
JQuantLIb has more than 1,000 classes containing convoluted code and complex math.
It's unmaintainable if there's not a team working on it and if there's no money keeping it alive.
For these reasons, the wrapper is the more sensible thing.

If you don't like the idea of the wrapper, JQuantLIb is there and there are lots of things to be done.

So, there are choices for all tastes ;-)

> Yes, why bother porting jquantlib over to github when we can just start over. It's just not worth migrating historic artifacts over from launchpad. I don't see any value in doing that.

Launchpad works well enough and Bazaar works well enough.
By the way, Bazaar is pretty close to SVN and Mercurial, far simpler and easier than Git, so it's not a blocker. You just have to install it:

$ apt-get install bzr qbzr bzrtools

Unfortunately, there's no plugin for IntelliJ or Netbeans.
But I guess (not sure!) that Eclipse supports Bazaar.

I've copied the repository from Launchpad to Github.
They are in sync at the moment.

http://github.com/frgomes/jquantlib

Future work will be done only on Github.

We still need to pick those issues we are going to work on from Launchpad and manually enter them into Github issue management.

Thanks

-- Richard Gomes