Bugzilla Bug 6967

Implement anything that helps (re)building, testing and maybe reloading
resource types when using Eclipse.

For building as found out by Alec IIRC (and recently rediscovered by me...)
instead of packaging all classes into JARs and copying them to
$WEBAPP_HOME/WEB-INF/lib/ we could compile them directly to
$WEBAPP_HOME/WEB-INF/classes/ (we can always keep a separate JAR task).

Sadly Eclipse 3.4 does not allow build output directories outside of the
project hierarchy, so we would have to use a symlink.

For Unix-like development environments (Linux, MacOSX, Cygwin, ...), we can
simply use `ln -s` or the "symlink" Ant task:
http://ant.apache.org/manual/OptionalTasks/symlink.html

For NT-based younger-than-W2k Windows < Vista we may be able to use NTFS
junction points ( http://en.wikipedia.org/wiki/NTFS_junction_point ), which for
our purposes works well enough like symbolic links (creation is not possible
under stock Windows,
http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx (Junction v1.05
By Mark Russinovich) seems the simplest tool to do it).
For Windows >= Vista, we should rather use real NTFS smybolic links (
http://en.wikipedia.org/wiki/NTFS_symbolic_link ).
Not sure yet if Ant "symlink" task itself handles those 2 cases correctly...

Windows environments can use symlinks with the linkd.exe provided by Microsoft.

http://support.microsoft.com/kb/205524

Yeah, I saw this one as well, but it seems more complicated to obtain than the
former, which is now also officially endorsed by Microsoft.

(I never thought I would say this but) too bad Vista was not such a success at
least for developers, else we could just use NTFS better stock implementation
and forget all about systems without POSIX symbolic links... well, except if
you want to develop from a (VFAT) USB key... ;)


Anyway, the Ant task does nothing under Windows, and indeed the task
documentation says:
> any operating system on which the command ln -s <linkname> <resourcename> is not a valid command on the command line will not be able to use action="single" or action="recreate"

Also it seems like Java won't handle (symbolic) links properly before the new
FS & IO API ("nio2") scheduled for JDK7... :/

Also on Windows XP the `fsutil` installed by default allows creation of (file)
hard links only! :( (from
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html#hardlinks
which also provides a GUI for everything links as a Windows Explorer shell
extension)

Implemented in revision 42455 the autopatching of the webapp's classes in
cluster node #1 from Eclipse when triggering a build there (e.g. when saving a
source file).

BTW comment #1 said:
> Sadly Eclipse 3.4 does not allow build output directories outside of the
> project hierarchy, so we would have to use a symlink.

This is correct but Eclipse fortunately has its own concept of symbolic links
(in UI: click on the "Advancted" button in the new folder creation wizard.
So basically everything up to and including comment #4 is interesting but
moot... :/


So to sum up, from comment #0:
> Implement anything that helps (re)building, testing and maybe reloading
> resource types when using Eclipse.

- (re)building has been completed in bug 6942 comment 8 (work started from 1st
comment) but has no entry point in Yanel documentation, see
http://lists.wyona.org/pipermail/yanel-development/2009-March/003299.html
- testing: nothing done in that area yet
- reloading: works but again no docs yet and "developer-visible names" in Ant
and Eclipse are cryptic, and with Tomcat for it to work at runtime one needs to
manually set up a reloaded context using configuration files

Urs also had a nice idea:
- source code: depended-upon resource-types now always have their source code
attached under Eclipse :) (provided they use the "new-style" importing Ant
build script)! Done in revision 42524 and revision 42523.

Also (TODO: document that properly):
- debugging: it also works if you:
  - start Tomcat in debug mode (using Eclipse plugins or directly
"catalina.sh/bat jpda start" (no support for that in yanel.sh/.bat
unfortunately))
  - create a debug configuration for the resource-type you want to debug (this
is a problem if you want to debug something spanning several, still working on
a solution)
    - the default port used to Tomcat is 8000, so one should simply use that
    - the method to use is "socket attach" or such
  - launch the debug configuration
  - set breakpoints in your resource-type or its dependencies: everything
should work as expected

The autopatching evoked in comment 5 seems not to work anymore with Eclipse
3.5, see bug 5155 comment 5 up to comment 2.

(In reply to comment #7)
> The autopatching evoked in comment 5 seems not to work anymore with Eclipse
> 3.5, see bug 5155 comment 5 up to comment 2.

Need to test again with Eclipse 3.5.1!

If we move not-yet-implemented xUnit testing support for individual
resource-types to another bug (which we should because it requires mocking most
of Yanel :o...), all that remains to be done is documentation: that be can be
done by another developer than me and I could just review...

Also copying the RT JARs into node1 app server webapp's is also implemented but
still undocumented (and the Ant task is still hidden).

Added public "maven:deploy-jar" target (primarily for Yanel developers, but if
customized can be used for other Maven repos) in r45303.