JDeveloper 11gR1 Bug in Tuning Node of ViewObject

Today I came across a bug in the tuning node of ViewObjects in JDeveloper 11gR1 (meaning all 11.1.1.x versions). For a prove of concept I played with the tuning options available for ViewObjectes in JDeveloper. The following image shows the the default tuning node of a ViewObject (it doesn’t matter if it’s based on an EntiyObject or not):

Default Tuning Node

Default Tuning Node

As I tested some options I eventually switched to the ‘Only up to row number’ radio button which enables the input field for the number of rows:

Tuning for '...up to row number'

Tuning for ‘…up to row number’

Nothing special there. Now if you delete the number (default is 10)

Delete Number from Field

Delete Number from Field

and ‘tab’ out of the input field, or click on any other field, you get an error dialog telling you that ‘(null) is not a valid fetch size value’.

Error Dialog

Error Dialog

OK, this is correct, but if you hit the OK button or the ‘x’ to close the dialog to put the number back in the dialog stays open, you can’t close it. You don’t get a chance to put the number back into the field. A first I had to kill JDeveloper through the task manager (I did that a couple of times ;)) until I found the following workaround:
            hit the Esc key
you may need to do this multiple times, but the dialog closes eventually and the last number is back in the input field.

This bug is fixed in the current JDeveloper 11gR2 (11.1.2.3.0) version!

Advertisements

JDeveloper 11.1.1.6.0: The Git Experience (Part 1)

End of November Oracle released a new JDeveloper version 11.1.1.6.0 Build 6229 (What’s new 11.1.1.6.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:

GIT Options Page 1

GIT Options Page 1

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.

GIT Options Page 2

GIT Options Page 2

GIT Options Page 3

GIT Options Page 3

GIT Options Page 4

GIT Options Page 4

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.

Test Java class

Test Java class

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.

'Version Application...'

‘Version Application…’

now we see Git as possible version control system

Hello Git

Hello Git

Now we follow the wizard

Git Import Wizard Page 1

Git Import Wizard Page 1

Git Import Wizard Page 2

Git Import Wizard Page 2

Git Import Wizard Page 3

Git Import Wizard Page 3

Git Import Wizard Page 4

Git Import Wizard Page 4

That’s it, easy enough. Now we see that the application is under source code control

Application after import

Application after import

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.

First Change

First Change

Next we need to commit the change to the local repository. For this we have some image buttons:

Image Buttons to work with changes

Image Buttons to work with changes

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.

Add File Dialog and Help

Add File Dialog and Help

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:

Get Version Histroy

Get Version Histroy

and we’ll see all versions which we can filter using the filter select one choice at top of the panel.

Version Histroy

Version Histroy

Lets check the differences between the two versions:

Difference between versions

Difference between 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

GitGui

GitGui

After some commits with msysgit we again look at the version history of the Java class

Version Histroy after msysgit commit

Version Histroy after msysgit commit

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.