How to publish your Gradle project to the Central Repository
Sonatype makes it easy to add your projects to the Central Repository with a free, public hosting service called OSSRH, that we recently wrote about here. Many developers have found this a very useful service and easy to use with Apache Maven. However, if you’ve started using Gradle, you may have wondered if you could continue using the service. The answer is absolutely YES.
We were talking about creating a guide for this, but someone in the community beat us to it. Yennick Trevels published an excellent guide in his blog that you can find here. We highly recommend checking out his post if you want to use Gradle to deploy artifacts to the Central Repository.
Publishing Your Artifacts to the Central Repository
Sonatype makes it easy to add your projects to the Central Repository with a free, public hosting service called OSSRH. We first blogged about this back in 2009, but given the growth in the community, we thought some of you may not have seen that post, so we decided to update it. (more…)
Goodbye SVN, Hello Git
We are moving both our public and private source repositories to Git for a few reasons:
- Git works better for people with slow or lagging connections
- Branch management is easy
- Submitting patches via a pull request is easier to deal with than a patch attached to a bug report
We started out with SVN mostly because that was what everyone was used to. A year ago or so, one of our remote developers started using a git-svn mirror to remove some of the latency issues they had with SVN. Someone else put together a ten page wiki on how to easily use a git-svn mirror and push back to the canonical SVN repo. As time went on, interest in git grew and new modules were created in git, instead of our SVN repositories. Finally there was a push to move everything to git.
Installing Nexus Open Source on a Windows Server
If you are considering Nexus Open Source, here is a quick-start video and PDF handout for installing Nexus on a Windows machine. The process takes about 3 minutes start to finish and can be summarized as “Download”, “Copy”, “Run a BAT Script”, “Go”.
This PDF covers the same ground as the video for those of you who are looking for something simple to print out.
Special Character Encoding Properties
The other week I listened to Dennis Lundberg’s presentation “Site creation with Maven” and learned something new. As most of us living outside the plain ASCII world have experienced, character encoding makes a big difference when it comes to ensuring that text remains readable. For XML files, the encoding can be defined through the XML header which makes it possible for an XML file reader to decide on the proper encoding. But for other types of files such as Java source files and properties files, the encoding has to be defined outside of the actual source file.
Even though encoding seems to be handled correctly in your environment, with your local language settings or some implicit default value, the best practice is to always explicitly define the character encoding. This will make sure that your build is portable and it will also protect you in the future in case some of your default values change. The bottom line is, just do it!
In the Maven world, you need to specify the character encoding for every plugin that processes source files or creates reports. It would have been great if this were made possible through a shared configuration element in the POM, but that would require an update to the POM model and that won’t happen until Maven 3.x. In the meantime, two special properties have been defined.
