Lightning talk from JavaZone 2012. As promised here are the notes, with pointers to more information.
Links to more information
Google code hosting: Getting started.
Example pom for Google hosted projects.
GitHub (getting started on front page).
Example project / pom for GitHub hosted projects.
Sonatype OSS Repository Hosting Service: Usage guide.
Blog post with more details than the above (but not up to date)
Guide from Apache.
About Open Source Licenses.
Script
Welcome to this talk titled Publish! It is about publishing an Open Source project.
I will try to convince you that this is not hard to do, and that you stand to benefit from doing such a thing.
My name is Tommy Skodje
I work for the consultancy Antares, we have a stand out in the hall.
I have programmed for some years now, but only yesteryear I opensourced my first project, test-data-control. A tool for exporting / importing data from database.
That was a good experience, and I want to share this with you.
First version
Now for the 9 steps I took to publish the project.
I created the project on Google Code Hosting and used project information to fill in Jira ticket on Sonatype OSS Repository Hosting Service.
That´s how I asked Sonatype to create Maven repositories for me.
There was not much to the creation forms - Googles is the big one with 6 fields (you have to select vcs and license).
Jira ticket needs the same information, plus urls to the project hosting, and groupId.
I got a reply on the ticket, asking me to change groupId.
So I did, and the next day my ticket was resolved and I could code and deploy my project to Maven repositories on Sonatype.
With this formalities around the project were done.
Releasing
After a while I was ready to stage a release - I did it using normal maven release procedure, which put my artifacts into Sonatypes Nexus.
I then logged in to Sonatypes Nexus, found my repository and pushed 4 buttons to release my staging repository.
The first time I released I commented my Jira ticket to let them know they should verify my project and turn on Maven Central synchronization if OK.
The next day Jira mailed me the reply and I found my artifacts in Maven Central.
Central Sync requirements
Before I could stage the first release, my pom needed at least the 12 lines on the left.
Javadoc and source artifacts has to be produced.
Artifacts signed using GPG.
Sonatype helps by providing oss-parent pom that defines tasks related to releasing, and they give nice instructions about how to install and set up GPG signing.
Project does not need to be Mavenized, but it needs a pom.
Licensing
I chose Apache v2. Applying it is easy - added LICENSE and NOTICE files on top level, and comment all source files.
NOTICE is for honoring inclusions - now that I published I needed to track licensing of libraries and code I include.
Subsequent versions
After the first release, it got a lot easier.
I should have
Project was almost coded ready when I took out the Jira ticket.
Then I refactored package structure and pasted in Copyright all over.
And then a complete rewrite in Scala…
I would have been better off starting with the formalities and no code. I chose a poor name - what a pity - project name is final. The other stuff is mutable.
Why
Curiousity and ambition got me started.
I wanted to learn more about opensourcing, and show off me and Antares.
But I soon realized that Open Source programming differs from inhouse-projects in many respects.
Theres was no restrictive firewall or policies. I could cod and commit whenever I had internet. I even submitted work from my iPhone.
Schedules and pressures were not the same either. I felt more pressure to code cleanly than quickly.
And with myself at the helm I could pursue my own agenda.
So I ported it to Scala.
I had just read the book and wanted some practice.
Clients would not mind implementation details.
That was a big job, I have done several other small stunts.
I now want to make a command-line utility of it that interpretes an external DSL.
There was a nice article in PragPub magazine that I am keen to follow up on, and I have also read too much about DSLs that I haven´t practiced yet.
And both should be a nice fit here.
I rarely get to do such things otherwise.
Normally, on daytime projects, I stop and do research when there is a need. Now, I can read stuff from the stream that may fit nicely, or that I really would like to try.
And I can!
Even if the project was «done» 2 months ago…
Having a side project facilitated deeper learning.
I tried to practice TDD from the start.
Many a time I gave thanks to my former self for doing that! Automated tests made it a lot easier to code a little now and then.
And also release quick changes that I needed on my daytime project.
That helped TDD click with me!
Going public was scary.
More than once I pondered my craftsmanship.
I did more beautifying, simplification, refactoring and testing than earlier.
Slowed me first, but I improved.
One day at work I realized I could do it, efficiently and confidently.
Publishing my work has driven me to evolve.
Being my own client has been wonderful.
I could sharpen my own tool and skills at the same time.
API cumbersome or lacking? I improved it. More usable with each reuse.
Many revisits makes this feel like growing SW.
And I gradually learned more about design, documentation and testing.
Also because I forget stuff between iterations, and I can see better when I start with fresh eyes.
Thank you
I really enjoy the project, tinkering with it, making it better every now and then, and learning by practicing. I would like to say thank you to Sonatype, Google, GitHub and all the other hosting sites for making this so convenient. And to Øystein Pettersen at Evry for telling me where I could get synchronization to Maven Central.