Hi again, everyone. I'm sorry that I've been too busy to do
anything on
the project for some time. I noticed Yana updated the sample
Eclipse
classpath earlier this week and I have just committed the
same change
for the Netbeans sample.
If you use NetBeans, let me remind you to copy this
project.xml file
from sandbox/ide/nbproject/ to sandbox/nbproject/ when
NetBeans is NOT
RUNNING!
I used eclipse a lot until about 2 years ago, when I
switched to
NetBeans. Since that time, I'm sure Eclipse has changed a
lot - Netbeans
certainly has! This makes me hesitant to say anything about
the way
Eclipse works, so please be patient if I don't get it
perfectly correct...
These two ide's have quite different philosophies and
architectures. I
believe it is important that we reduce wasted time within
our project by
trying hard to let everyone benefit from the best possible
ide setup.
This is not a simple matter.
NetBeans is a pure java application. It makes sophisticated
use of
ClassLoaders and runs debugged applications under completely
separate
system processes via the JVM's remote debugging interface.
If you look
at the build.xml for our project, you will see there is a
special ant
target to setup the debug process managed by NetBeans.
This means something rather ugly - NetBeans needs THREE
different
"classpaths" for a project... one to compile the
main source class
files, one to compile the test source class files, and
another to allow
the IDE to correalate the debugged JVM line numbers to the
source code.
All three need to be independently "correct" - and
are often different.
Of course, if you ask NetBeans to create a new project for
you, all this
ugly stuff is done "under the covers" by the
wizard and you don't see
how complex it is. It is the price required to support a
sophisticated
"non-standard" (to NetBeans) project under a
rather elegant execution
and debugging environment. I haven't done it myself, but
this design
allows you to attach the ide/debugger to an already-running
external
process.
On the other hand (and I certainly don't want to start an
IDE-war
here!), Eclipse is not "pure java" and its
build/debug architecture is
more internalised than that of NetBeans. Although Eclipse
can run ant to
build the project, that isn't what it does when you open the
project...
it compiles all the source files against its own version of
the
classpath. This is what is held in the
sandbox/ide/eclipse/.classpath
file. The "classpathentry kind=lib" lines define
the classpath used to
compile ALL the project sources (i.e. both main and test).
The
"kind=src" lines are used by the editor and
debugger to resolve import
statements. When you debug an application under Eclipse, the
ide needs
to know everything because the debugged jvm runs within the
eclipse process.
Anyway, I have committed the equivalent classpath entries to
make
NetBeans match the current Eclipse definitions. However, I
want to make
those of you who are interested aware of several outstanding
issues that
I haven't resolved...
1. I have NOT yet updated the build.xml target called
"debug-single". In
other words, I am not sure that debugging a unit test under
NetBeans
will be successful because the classpath and sourcepath
might not be
correct. I have put this on my list of "things to
do".
2. The classpath list needs to (somehow) distinguish between
the main
and test source trees. Eclipse doesn't care, but NetBeans
does.
Currently, I've only separated junit and the compiled
classes of our own
project. Are there any other jars that are needed
exclusively by one
source set?
3. We really ought to keep the classpath list minimal. If
more than one
jar contains the same fully-qualified class, we run the risk
of the two
IDE's ClassLoaders loading different versions of the same
class.
4. Currently, the new classpath is very long and contains a
lot of
platform-dependent jars. I am worried this is a bad idea,
beyond my
point 3 above, but can't be sure yet.
Just a final thought. It ought to be possible to define a
Property (or
several) that could be resolved by NetBeans when it opens
the project.
Unfortunately, I haven't yet found a way to use the existing
properties
within build.xml. This is because NetBeans processes
project.xml (with
its classpaths) long before it gets to run ant against the
build.xml. In
principle, we ought to be able to devise a set of properties
that
NetBeans (and Eclipse) could resolve to the appropriate
classpaths when
they open the sip-communicator project. Does anyone have any
idea
whether this is possible, because it could reduce the risk
of
introducing obscure ide-related debugging problems.
Regards,
Brian
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribe sip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
|