Page History

Producing Source Artifacts

...

1. untar and cd into the proton source tarball
2. run "mvn -P apache-release deploy" (note that for this step to succeed you need to do mysterious and annoying things like putting your apache password in cleartext inside your .m2/settings.xml file)
3. go to https://repository.apache.org/index.html, login and click on one of the Staging links (Repositories I think) and find the thing that maven just uploaded (it should say open or opened or something like that and have a recent date)
4. poke at the clumsy ui until you figure out how to "close" it, and then record the URL it gives you for the repo

Testing the

...

tarball

The challenge here is the variety of different environmental variables to factor in. For proton-c itself we have different architectures to contend with as well as different cmake versions and different versions of the few key libraries we depend on (e.g. openssl). On top of this, for each binding we have not only the language version, but also the version of swig available, and even if those are the same, the configuration of the interpreter may vary depending on which OS we're building on.

...

TODO Java installation is not yet implemented as at Jan 2013 so the best you can do is to check that proton-api, proton-j-impl and proton-jni jars have been built under ./build/.

Test

Use the instructions in READ to run the tests.

Notes

The only stage here that really needs to be done by one person is producing the release tarballs. I expect as we wish to offer more binary artifacts and producing them becomes more complex (e.g. requiring a windows box) we will need to distribute the responsibility for producing binaries, e.g. have a java developer produce the java binaries, have a windows developer produce windows binaries, have a ruby developer produces gems, and so forth.