OK - let's remove the .project/.classpath files and add them to svn:ignore.
One argument has been that having a shared set of compiler settings
(via .settings) means that there's some common policy on which
compiler warnings are consistently addressed. We could fix that via a
shared findbugs or checkstyle configuration (& a commitment to use
the tool!)
No warnings!
No warnings!
No unused imports!
Seriously, the tools run too late. People here heck in stuff with
warnings which makes life difficult for a RM because when working as
scale, the only reasoable position is no warnings, so you can see one
appear. Counts are costly - the warning still need checking.
Another argument has been that it's easier to get up and running
quickly from checking out the source tree.
Unfortunately, that no long works :-( Sigh.
maven is now required.
And we are also expecting the whole code tree to be checked out.
The third reason to not get rid of .classpath is that it's currently
how the command line apps instantiate the classpath when invoking
tools in the development version. See bin/jena_path and
bin/tdb_path.
Don't know if it's the best solution but in jena-fuseki, it's done
differently, there is a cached, edited (by script) output of mvn
dependency:build-classpath (run_cp).
Caching is necessary - it is way too slow otherwise.
So: solvable problems, but there are costs involved.
Yes - writing the documentation needs doing ... I tweaked it recently
but it needs rework and made consistent across the multiple places it
comes up.
From the sounds of it, people have multi-module m2e to work on jena.
What about mvn eclispe:eclipse?
(Both of those do not always work, for example, it used to break on
any23 leaving broken and illegal files around.)
Now, does any know how to get m2e/eclipse:eclipse to put the source
folders in sensible and consistent order? (that's rhetorical).
Andy
