== Knowing Every Detail ==

== Knowing Every Detail ==

Once a customer of the [[NetBeans Platform]] invited me for a consultation. It is not common to send the creator of a framework for a consultation, the usual strategy is to send the junior guy to find out if they can spell [[Java]]. Later send somebody more experienced and only if every effort fails, ask the guru. But even for me, as a creator of the [[NetBeans Platform]], it is important to see real customer from time to time, so I took the opportunity to visit such important customer.

Once a customer of the [[NetBeans Platform]] invited me for a consultation. It is not common to send the creator of a framework for a consultation, the usual strategy is to send the junior guy to find out if they can spell [[Java]]. Later send somebody more experienced and only if every effort fails, ask the guru. But even for me, as a creator of the [[NetBeans Platform]], it is important to see real customer from time to time, so I took the opportunity to visit such an important customer.

Certainly I can talk about architecture decisions and explain how to use [[NetBeans]] [[API]]s on a higher level, but when it comes to details, I may often be in total [[cluelessness]] situation (there is a lot of [[NetBeans]] [[API]]s check at http://bits.netbeans.org/7.3/javadoc/ and we design them as a team). As a result my most common answer to customer questions was: ''I don't know. Let's put a breakpoint somewhere''!

Certainly I can talk about architecture decisions and explain how to use [[NetBeans]] [[API]]s on a higher level, but when it comes to details, I may often be in total [[cluelessness]] situation (there is a lot of [[NetBeans]] [[API]]s check at http://bits.netbeans.org/7.3/javadoc/ and we design them as a team). As a result my most common answer to customer questions was: ''I don't know. Let's put a breakpoint somewhere''!

[[Debugger]] can be useful even for understanding a system without a source code. It is just essential to know where to place a breakpoint. Once I was trying to understand the behavior of [[iOS]]'s '''WebUI''' - of course its not open source, but luckily [[Gdb]] (as well as many other [[debugger]]s) can place a breakpoint to a method and stop the execution when the method is called. As we needed to find out why the '''WebUI''' does not load a resource using our [[URL]],

[[Debugger]] can be useful even for understanding a system without a source code. It is just essential to know where to place a breakpoint. Once I was trying to understand the behavior of [[iOS]]'s '''WebUI''' - of course its not open source, but luckily [[Gdb]] (as well as many other [[debugger]]s) can place a breakpoint to a method and stop the execution when the method is called. As we needed to find out why the '''WebUI''' does not load a resource using our [[URL]],

we added a breakpoint to constructor of '''NURL'''. As soon as the breakpoint was hit, we could inspect the stack, see names of methods and even values of registers. Based on that we could get a clue of what was going on.

we added a breakpoint to constructor of '''NSURL'''. As soon as the breakpoint was hit, we could inspect the stack, see names of methods and even values of registers. Based on that we could get a clue of what was going on.

Once I was inspecting a closed source [[Java]] implementation of a [[Mylyn]] connector [[API]]. The system had three layers: User interface and connector [[API]] was [[open source]], the library in middle was not. By placing breakpoints into the bottom connector [[API]] I obtained very [[good]] understanding of what the blackbox in middle does. It is all about knowing where to place the breakpoints.

Once I was inspecting a closed source [[Java]] implementation of a [[Mylyn]] connector [[API]]. The system had three layers: User interface and connector [[API]] was [[open source]], the library in middle was not. By placing breakpoints into the bottom connector [[API]] I obtained very [[good]] understanding of what the blackbox in middle does. It is all about knowing where to place the breakpoints.

[[Image:DebugMavenBuild.png|thumb|right]]

[[Image:DebugMavenBuild.png|thumb|right]]

Do you know the difference between [[Ant]] and [[Maven]]? In [[Ant]] you described what to do and make calls to individual [[Ant]] tasks. On the other hand in [[Maven]] you describe what should be done and let the system do it for you. That is more [[Declarative Programming|declarative]], but also more [[framework]] like: often it is hard to find out why some actions are not performed the way you'd like them to be.

Do you know the difference between [[Ant]] and [[Maven]]? In [[Ant]] you describe what to do and make calls to individual [[Ant]] tasks. On the other hand in [[Maven]] you describe what should be done and let the system do it for you. That is more [[Declarative Programming|declarative]], but also more [[framework]] like: often it is hard to find out why some actions are not performed the way you'd like them to be.

Recently we were writing a [[Maven]] plugin in [[Ant]] (yes, that is possible, both projects are supported by [[Apache]] foundation and as such they seek some synergy). Documentation how to achieve this is available, however it covers only the most common [[usecase]]s. When you need to take it to extreme, use not only simple [[Ant]] script, but rather a set of files that work in [[harmony]], you need to understand what is happening. The only way to do it is to use [[debugger]]. Can you debug your build?

Recently we were writing a [[Maven]] plugin in [[Ant]] (yes, that is possible, both projects are supported by [[Apache]] foundation and as such they seek some synergy). Documentation how to achieve this is available, however it covers only the most common [[usecase]]s. When you need to take it to extreme, use not only simple [[Ant]] script, but rather a set of files that work in [[harmony]], you need to understand what is happening. The only way to do it is to use [[debugger]]. Can you debug your build?

Have your [[Java]] application exited without a reason? Try to place breakpoint to {{JDK|java/lang|System}}.exit(). If that does not work, create an ''exception'' breakpoint to stop when an exception is thrown.

Have your [[Java]] application exited without a reason? Try to place breakpoint to {{JDK|java/lang|System}}.exit(). If that does not work, create an ''exception'' breakpoint to stop when an exception is thrown.

Trying to influence behavior of your application with a system property and it does not work? Place a conditional breakpoint to {JDK|java/util|Properties}}.getProperty(name) to stop when ''name'' is equal to name of your property.

Trying to influence behavior of your application with a system property and it does not work? Place a conditional breakpoint to {{JDK|java/util|Properties}}.getProperty(name) to stop when ''name'' is equal to name of your property.

Curious to know why a communication to a [[HTTP]] server fails? Place a breakpoint to {{JDK|java/net|URL}} constructor. Etc.

Curious to know why a communication to a [[HTTP]] server fails? Place a breakpoint to {{JDK|java/net|URL}} constructor. Etc.

Once I was inspecting a closed source [[Java]] implementation of a [[Mylyn]] connector [[API]]. The system had three layers: User interface and connector [[API]] was [[open source]], the library in middle was not. By placing breakpoints into the bottom connector [[API]] I obtained very [[good]] understanding of what the blackbox in middle does. It is all about knowing where to place the breakpoints.

Once I was inspecting a closed source [[Java]] implementation of a [[Mylyn]] connector [[API]]. The system had three layers: User interface and connector [[API]] was [[open source]], the library in middle was not. By placing breakpoints into the bottom connector [[API]] I obtained very [[good]] understanding of what the blackbox in middle does. It is all about knowing where to place the breakpoints.

Have your [[Java]] application exited without reason? Try to place breakpoint to {{JDK|java/lang|System}}.exit(). If that does not work, create an ''exception'' breakpoint to stop when an exception is thrown.

Have your [[Java]] application exited without a reason? Try to place breakpoint to {{JDK|java/lang|System}}.exit(). If that does not work, create an ''exception'' breakpoint to stop when an exception is thrown.

Trying to influence behavior of your application with a system property and it does not work? Place a conditional breakpoint to {JDK|java/util|Properties}}.getProperty(name) to stop when ''name'' is equal to name of your property.

Trying to influence behavior of your application with a system property and it does not work? Place a conditional breakpoint to {JDK|java/util|Properties}}.getProperty(name) to stop when ''name'' is equal to name of your property.

we added a breakpoint to constructor of '''NURL'''. As soon as the breakpoint was hit, we could inspect the stack, see names of methods and even values of registers. Based on that we could get a clue of what was going on.

we added a breakpoint to constructor of '''NURL'''. As soon as the breakpoint was hit, we could inspect the stack, see names of methods and even values of registers. Based on that we could get a clue of what was going on.

Once I was inspecting a closed source [[Java]] implementation of a [[Mylyn]] connector [[API]]. The system had three layers: User interface and connector [[API]] was [[open source]], the library in middle was not. By placing breakpoints into the bottom connector [[API]] one can get very good understanding of what the blackbox in middle does. It is all about knowing where to place a breakpoint.

Once I was inspecting a closed source [[Java]] implementation of a [[Mylyn]] connector [[API]]. The system had three layers: User interface and connector [[API]] was [[open source]], the library in middle was not. By placing breakpoints into the bottom connector [[API]] I obtained very [[good]] understanding of what the blackbox in middle does. It is all about knowing where to place the breakpoints.

Have your [[Java]] application exited without reason? Try to place breakpoint to {{JDK|java/lang|System}}.exit(). If that does not work, create an ''exception'' breakpoint to stop when an exception is thrown.

Have your [[Java]] application exited without reason? Try to place breakpoint to {{JDK|java/lang|System}}.exit(). If that does not work, create an ''exception'' breakpoint to stop when an exception is thrown.

we added a breakpoint to constructor of '''NURL'''. As soon as the breakpoint was hit, we could inspect the stack, see names of methods and even values of registers. Based on that we could get a clue of what was going on.

we added a breakpoint to constructor of '''NURL'''. As soon as the breakpoint was hit, we could inspect the stack, see names of methods and even values of registers. Based on that we could get a clue of what was going on.

Once I was inspecting a closed source [[Java]] implementation of a [[Mylyn]] connector [[API]]. The system had three layers: User interface and connector [[API]] was [[open source]], in library in middle was not. By placing breakpoints into the bottom connector [[API]] one can get very good understanding of what the blackbox in middle does. It is all about knowing where to place a breakpoint.

Once I was inspecting a closed source [[Java]] implementation of a [[Mylyn]] connector [[API]]. The system had three layers: User interface and connector [[API]] was [[open source]], the library in middle was not. By placing breakpoints into the bottom connector [[API]] one can get very good understanding of what the blackbox in middle does. It is all about knowing where to place a breakpoint.

Have your [[Java]] application exited without reason? Try to place breakpoint to {{JDK|java/lang|System}}.exit(). If that does not work, create an ''exception'' breakpoint to stop when an exception is thrown.

Have your [[Java]] application exited without reason? Try to place breakpoint to {{JDK|java/lang|System}}.exit(). If that does not work, create an ''exception'' breakpoint to stop when an exception is thrown.

=== Debugging without Source Code ===

=== Debugging without Source Code ===

[[Debugger]] can be useful even for understanding a system without a source code. It is just essential to know where to place a breakpoint. Once I was trying to understand the behavior of [[iOS]]'s '''WebUI''' - of course its not open source, but luckily [[Gdb]] (as well as many other [[debugger]]s) can place a breakpoint to a method. As we needed to find out why the '''WebUI''' does not load a resource using our [[URL]],

[[Debugger]] can be useful even for understanding a system without a source code. It is just essential to know where to place a breakpoint. Once I was trying to understand the behavior of [[iOS]]'s '''WebUI''' - of course its not open source, but luckily [[Gdb]] (as well as many other [[debugger]]s) can place a breakpoint to a method and stop the execution when the method is called. As we needed to find out why the '''WebUI''' does not load a resource using our [[URL]],

we added a breakpoint to constructor of '''NURL'''. As soon as the breakpoint was hit, we could inspect the stack, see names of methods and even values of registers. Based on that we could get a clue of what was going on.

we added a breakpoint to constructor of '''NURL'''. As soon as the breakpoint was hit, we could inspect the stack, see names of methods and even values of registers. Based on that we could get a clue of what was going on.

Recently we were writing a [[Maven]] plugin in [[Ant]] (yes, that is possible, both projects are supported by [[Apache]] foundation and as such they seek some synergy). Documentation how to achieve this is available, however it covers only the most common [[usecase]]s. When you need to take it to extreme, use not only simple [[Ant]] script, but rather a set of files that work in [[harmony]], you need to understand what is happening. The only way to do it is to use [[debugger]]. Can you debug your build?

Recently we were writing a [[Maven]] plugin in [[Ant]] (yes, that is possible, both projects are supported by [[Apache]] foundation and as such they seek some synergy). Documentation how to achieve this is available, however it covers only the most common [[usecase]]s. When you need to take it to extreme, use not only simple [[Ant]] script, but rather a set of files that work in [[harmony]], you need to understand what is happening. The only way to do it is to use [[debugger]]. Can you debug your build?

The good thing about [[Maven]] and its [[NetBeans]] IDE integration is that debugging your build is easier than ever. Just execute your build (by invoking any target on your project), let it fail and then restart it in debug mode. Press the yellow arrow in the output window and when a dialog pops up, select ''debug [[maven]] build''. See the picture for visual explanation.

The good thing about [[Maven]] and its [[NetBeans]] IDE integration is that debugging your build is easier than ever. Just execute your build (by invoking any goal on your project), let it fail and then restart it in debug mode. Press the yellow arrow in the output window and when a dialog pops up, select ''debug [[maven]] build''. See the picture for visual explanation.

This kind of side by side debugging is useful for finding out what is wrong when things don't happen. Because we had the old [[Equinox]] version which supposedly worked fine one could put a breakpoint to the place that should be executed, when the breakpoint is hit in the old version, just remember the stack. The problem in the new [[Netbinox]] version had to be along the stack. Placing another breakpoint (or breakpoints - depends on luck) to methods higher on the stack must once reveal a place where the code behaves the same in both versions. Then one could again switch to line by line debugging and find out where the difference between [[Equinox]] and [[Netbinox]] is.

This kind of side by side debugging is useful for finding out what is wrong when things don't happen. Because we had the old [[Equinox]] version which supposedly worked fine one could put a breakpoint to the place that should be executed, when the breakpoint is hit in the old version, just remember the stack. The problem in the new [[Netbinox]] version had to be along the stack. Placing another breakpoint (or breakpoints - depends on luck) to methods higher on the stack must once reveal a place where the code behaves the same in both versions. Then one could again switch to line by line debugging and find out where the difference between [[Equinox]] and [[Netbinox]] is.

Side by side debugging is not useful only when we are rewriting one system to new version. Even if something is wrong when we are using a [[framework]], we can usually find a tutorial or demo application that is supposed to perform similar thing as our application. At that moment, we can compare the behavior of working demo, with misbehavior of our application. Side by side debugging is useful for everybody.

Side by side debugging is not useful only when we are rewriting one system to a new version. Even if something is wrong when we are using a [[framework]], we can usually find a tutorial or demo application that is supposed to perform similar thing as our application. At that moment, we can compare the behavior of working demo, with misbehavior of our application. Side by side debugging is useful for everybody.

=== Insufficient Documentation of [[Maven]] Tasks ===

=== Insufficient Documentation of [[Maven]] Tasks ===