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-helpsip-communicator.dev.java.net
|