Replace vijava with yavijava in your JVM based projects

Do you currently use vijava? Have you noticed how the forums are kind of dead (meaning lots of questions, but no one from the project answering those questions), and there have not been any more community releases since 2013 or so ending with 5.5 beta? I noticed these things, and so I did something about it. I forked the project and started maintaing it. I have done a lot of work on the project. I have added logging using log4j. I have added the ability to RESET VCENTER ALARMS FROM RED TO GREEN. I have fixed several bugs including a bug where every single exception was being wrapped in a RemoteException causing you to have to check the exception.getCause() to find the underlying exception instead of being able to catch normal vCenter exceptions. I have refactored the code allowing you the user to provide your own HTTP clients should you need to, and even added a great deal of tests to the code (this is an ongoing work in process). I also converted the project to use gradle. This makes building the project a snap.. But wait theres more!! I fixed a bug in the InventoryNavigator which made the 5.5 release not work properly with vSphere 6.0.. speaking of 6.0 I have been hard at work adding support for vSphere 6.0 and Im happy to announce the beta release is done and available right now! With the help of people from the community work is being done RIGHT NOW to add SPBM support to yavijava as well!! One of the best parts about all of this is that I have maintained compatibility with vijava so switching to yavijava is painless for you the user!

So.. How do you switch? Switching is simple. If you have a project using maven you can simply update your pom, or gradle, or what ever to point at the yavijava repo. As of this blog post the current stable release is 5.5.11. If you are just grabbing the jar file to include in your project some other way thats fine too. Please be aware that I did introduce new dependencies, so if you are manually downloading jar files (you should consider stopping that and moving to gradle its super easy to do) be sure to check the build file for the latest requirements.

If you do run into any issues please report those issues on the GitHub issue tracker. When you submit an issue please consider reading over this basic guide I created. If you do not have a bug but just have a question, you are welcome and encouraged to open an issue and ask your question there, or join the web chat and ask there, just be sure if you cant wait around for an answer to open a GitHub issue.

I really look forward to growing the community and bringing it new life. Please help me spread the word about yavijava, and welcome to the community!

yavijava 6.0 beta release ready for vsphere 6.0

I’ve been hard at work adding support for vSphere 6.0 to yavijava, the vijava fork. Im happy to announce that I am done and ready for a beta release. I am not going to push this to public maven right now. For those of you who want to test this release out please download the release from GitHub. Next follow these simple instructions to build a jar.

  • Unzip the 6.0.01b1.zip file
  • Enter the yavijava-6.0.01b1 folder
  • On Linux or Mac use ./gradlew build
  • On Windows use gradlew.bat build

A jar file will be built for you and it will be located in the build/libs directory.

If you run into any issues please please please report them to me so I can get them fixed. Simply go to https://github.com/yavijava/yavijava/issues and open a new issue.
Enjoy!

How to contribute to an opensource project like a boss

So you found a cool project online and its opensource and now you want to give some of your time and efforts back to the community, but you dont know where to start. This blog post should help get you started and help you get your code accepted on just about any project out there.

The first step you should take is to read the documentation that comes with the project. A great place to start is often the README in the project. Generally you will find all kinds of info in this file. Some of that information may be code standards, where to find help, TODO lists, or just general project guide lines.

Next get familiar with the tools used in the project. This could mean having to learn to use a new revision control system such as git with a focus on using it via github or bitbucket. Many projects have some special requirements when it comes to their source code. You do not have to be a master with these tools, but you should at least understand how to do some basic tasks with them. For example, with projects using git and github you should understand forking, branching, fetching, merging, pushing, and most importantly pull requests. Its OK to ask for help getting these things done, and you can generally find where to get that help in the README.

Next it may be helpful for you to look at the rest of the code in the project, or at least some of it. I know this may be a lot of work because some projects are so large. Maybe you don’t need to see every line of every piece of code but it will help to look at some of it to get an idea of how the rest of the code is written so that you do not camelCase where the rest of the project uses underscore_syntax.

Next you should be open to community feedback. Opensource development generally speaking works differently than what you may be used to doing at work. Most projects I have worked on have some kind of peer review system where community members and projects owners will look at your code and make sure it meets the code standards, and has logic in it that is easy to follow and makes sense. These reviewers may ask you to make changes, but don’t take it personally. This feedback should not be taken as a personal attack. Remember you are going to donate this code and you may never come back again, so it will be up to other community members and project owners to maintain it. You may be doing this on your free time, but odds are that so are some if not all of the other people reviewing your code. Generally speaking no one will ask you to make changes to your code that they wouldn’t expect of their own code.

On the topic of changes no one is forcing you to make these changes. Generally speaking it is just an ask. If you don’t want to make the changes kindly tell the reviewers something like “Im sorry I am not interested in making these changes, please feel free to take my code if you can”. Most projects would rather have working code that needs to be “reformatted” than have nothing while others may not be interested in your code if you don’t make the changes.

Finally and this may seem very obvious but try to write good, well documented, clean code that is easy to follow and understand. I have been doing this for almost 15 years now and I have never run into some code where I said “Damn this documentation is way too good, and there is just way too much of it”, and I am willing to bet I never will. Often it is the opposite of that and I am cussing as I read through line by line trying to figure out how or why something is the way it is.

If you follow these steps, or suggestions as they really are, it should help the process be very smooth and pain free for all parties involved. If you have any suggestions about things that I should add to this list please feel free to let me know. I would love your feedback. I hope this blog post will be helpful to someone out there who is thinking about getting into working on opensource projects.