[sip-comm-dev] Adding profiling support to SC's tree


Hi guys,
I've prepared a patch to add the profiling support for Netbeans and Eclipse
(TPTP). Some files need to be added in ide/ folder.
Is it possible?


Thiago 'bolaum' Borges Abdnur
"Trust no one..."
- Deep Throat (The X-Files)


Over the years, I've periodically tried to keep the NetBeans project.xml file up-to-date. I watch out for changes to the Ant build.xml and the Eclipse .classpath files in the source tree, but am not always observant enough.

At the moment, I am trying to resolve several issues with the current SVN trunk and my own NetBeans IDE. Although I am sure I will sort them out and eventually commit my changes, my instincts tell me this is an ongoing problem that needs to be addressed intelligently.

The real problem (it seems to me) is that we would like to maintain THREE different files that all embody the same metadata relating to the compile, test and debug classpaths.

In the ideal world, our two IDE's would refer to the Ant build.xml, because it is the authoritative base for this classpath information. Currently, this is not possible.

In a nearly-ideal world, our two IDE's would share the same metadata in a common format. This isn't likely to happen in my lifetime!

We could set the classpaths up as separate properties files... Ant could then include the properties at run-time, although it would have the disadvantage of making the build more complex and fragile. I do not think this is a great idea, because I don't (at this stage) know how to make Eclipse and NetBeans load their IDE project classpaths from external properties files.

If everyone agrees with my comments so far, that only leaves us with three documentation-and-procedure solutions:-

1. Create a FOURTH file that lists every element in the three classpaths (compile, test and debug). The list elements should be clear and individually documented, e.g. say WHY we need both lib/bundle/log4j.jar and lib/installer-exclude/log4j-1.2.8.jar (I don't know why!) Changes would be made to the new file and then propagated to the existing three files as appropriate.

With this approach, we would have documentation for what-and-why we put into build.xml. It would make it MUCH simpler for individuals to monitor and update the separate Eclipse and NetBeans project files. You could say the scheme would become less fragile because, at the moment, it is difficult to decide whether to trust build.xml (the NetBeans debugger uses it but Eclipse does not), or to trust .classpath (used by Eclipse, but not Ant).

2. Possibly restructure the classpath logic in build.xml, AND insist on a LOT more in-line documentation about each element.

This has the advantage of appointing build.xml as the single authoritative origin of all classpath metadata. Eclipse and NetBeans classpath files need only be synchronised (unambiguously) with build.xml. The disadvantage is that build.xml will become even bigger.

3. Create some sort of Ant automation process that would propagate the classpaths from build.xml into the two IDE project files.

This option sounds wonderful in theory, but I do not think it is realistic!

My vote is for option 2 because:-

a) we would not create yet another classpath file in the source tree.
b) we would introduce a definite hierarchy of trust between the existing three files.
c) we would introduce a new standard - no-one should change the build classpath without documenting INLINE why that change is needed. (I realise you can trawl through the SVN change log, but that is another seldom-trustworthy source of metadata).
d) developer effort would be reduced and delegated. You should always change build.xml first and, if you don't understand the IDE files, leave them for someone else to update. The downstream IDE changes should then become trivial for someone who understands the way these files are used.

What do you all think?


To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net