End of November Oracle released a new JDeveloper version 188.8.131.52.0 Build 6229 (What’s new 184.108.40.206.0) which introduces Git support as one of the new features.
After a short break in my busy schedule I tried out the new Git support and decided to write a multi part blog series about it. First I thought about writing it all up in one post, but the plenty available options would make this more like a book😉. So in this first part I run through the basics of Git support in JDeveloper, showing how to version an application using Git (locally), make changes to the project and show some parts which need some improvement from Oracle. The next part drills into branching and merging of projects and remote Git repositories.
Lets start with the obvious, a look at the available documentation. You find the documentation in the ‘Developing in Teams’ section of the JDeveloper internal documentation which is available via the ‘Help’ menu. You can search for ‘git’ using the ‘Help’ menu to get there fast. Looking at the first chapter it looks like Git has not added to all available topics. The ‘About the Available Versioning Systems’ only shows SVN, Concurrent Version System (CVS), Perforce, Serena Dimensions, ClearCase and Team System. However I assume that this will be fixed in an upcoming version of JDeveloper. There are more thinks which need to be reviewed in my opinion. I point them out whenever I talk about the specific topic.
A new chapter ‘Using Git with JDeveloper’ has been added which covers the basics of working with Git. My first impression is that the doc is written from the point of view of the Team extensions for JDeveloper because I couldn’t find the ‘Team’ menu as I don’t have a Team server available on my laptop. However, most options are reachable through right clicks, which then reveals the ‘Team’ menu, or at least parts of it. I encourage you to at least scan this documentation. If you never heard of Git you should search the Web for a introduction to Git first.
Leaving the documentation, lets start to play with Git. A short overview over the configuration option of Git:
This first page gives you the option to define some default text which the you can use when committing changes to the reposritory. Once you add a template they are shown in the dialog. like in the image below. I didn’t find out if you can add some tags to the templates which expand later to text like ‘author’. In my sample the text is not very intelligent, but it’s only to show the feature. The ‘/’ you see are line breaks which are added in the template.
As you see there isn’t much to configure in the global options. All other configurations are done on application level which we start looking into right now. We start with a test case, an generic Java application, which consists of just one Java class with a main function at the beginning.
As with SVN we start with ‘Versioning’ the application which we reach via a right click on the application work space, or the ‘Application’ menu, then use the ‘Version…’ menu.
now we see Git as possible version control system
Now we follow the wizard
That’s it, easy enough. Now we see that the application is under source code control
and we find the first difference from the SVN view. We see that the project uses the ‘master’ version which is equal to the SVN ‘trunk’ version. Opening the tree in the ‘Version Control’ panel, we see the branches node and below it the local branch where we see the ‘master’ version.
OK, next we start to make some changes. First lets add a public method to the sole Java class. Right after this, save the change and open the ‘Pending Changes’ panel to see if the change is visible there.
Next we need to commit the change to the local repository. For this we have some image buttons:
the green plus sign is used to add files to the ‘staged index’. The ‘staged index’ holds all files which are later committed in one transaction. I call this a ‘commit set’. The button next one opens the commit dialog where you add a comment to the commit set. If you click the commit button right of the green plus sign you see the commit dialog, together with the changed file, but committing will tell you that there is nothing to commit from the ‘staged index’ or the ‘commit set’. That’s a difference to the SVN work flow. Using Git, changed files are first staged in an index, or a commit set. Only after this you can commit all files in the index or set together in one transaction.
Clicking the green plus sign opens a dialog which lets you add changes files. However, when you check the help for this dialog you get a kind of confusing help which tell you that you use this dialog if you add new files to the repository. This is not the case, so lets ignore this and add the changes file.
Once the file is added to the ‘commit set’ or ‘staged index’ you’ll notice, that the green plus sign gets gray, still the file is visible in the pending changes panel. Only after clicking the ‘commit’ button, right of the green plus button, adding a comment, or selecting one from the predefined templates, and closing the dialog with the OK button, the panels gets cleared. At this point the change is committed in the local repository.
To visualize this open the ‘Version History’ of the Java class:
and we’ll see all versions which we can filter using the filter select one choice at top of the panel.
Lets check the differences between the two versions:
This all looks like the we know it from SVN.
Finally, to conclude this first part lets check if we can work with an external Git application too. For this test I use msysgit and GitGui which comes together with the installation. The image below shows the change before the last commit
After some commits with msysgit we again look at the version history of the Java class
Thankfully, the two different applications (JDeveloper and msysgit) are working well together. Up to now I have not found anything which make working with the different apps break the whole version control system. That is a big step forward!
That’s it for the first part. Stay tuned for the next part where I show how to clone a repository from a remote Git server and how to work with branches.