Since javacvs filesystem will no longer be used in the NetBeans 4.0,
the build script could be changed to build just 'libsrc'. Because
javacvs.jar module will not work in projects build anyway, we can do
following changes:

1) In build.xml compile and jar only sources in libsrc
2) Create manifest-lib.mf to describe cvslib.jar, or modify the
current manifest.mf. The library will either stay in modules/ext or it
will be installed into modules/autoload as a module. If it would be an
autoload module, it could be downloadable through autoupdate if
necessary.
3) Assuming that no one will maintain and actively use javacvs
filesystem, remove sources under 'src' from the trunk. A private
branch can be created on the 'src' folder if needed.
4) All issues in Issuezilla will be separated into two parts: library
or filesystem. All filesystem issues will be probably resolved as
"wontfix" unless someone would wish to maintain it.

Comments?

No comments so far?

I had a discussion with Yarda on this topic. The conclusion is, that
is should be possible to have both javacvs/src and javacvs/libsrc on
the main trunk and build just javacvs/libsrc in the standard IDE
build. There can be another build script for the filesystem part
javacvs/src and the JavaCVS filesystem module can be made available on
autoupdate.

So the changes will be:
1) javacvs/build.xml will compile and build just javacvs/libsrc
2) There will be javacvs/fs/build.xml, that will compile and build
javacvs/src
3) There will be manifest-lib.mf (for the library) and manifest-fs.mf
(for the filesystem).
4) There will be a new sub-component in Issuezilla "library". All
issues, that are submitted for the library will be moved to that
sub-component and these will be tracked and fixed as IDE bugs. All
other issues will be left for optional fixes.
5) The javacvs filesystem will be made available on the autoupdate.
6) The cvs-profile module under vcsgeneric can start using cvslib.jar
(autoload module) as soon as issue #33693 is implemented.

Please speak up if you disagree with this plan. If no one objects,
I'll start implementing this next week.

I've revised this proposal once more.
It would be good if we do not have to branch the module to
prj40_prototype branch. So we need that the code for dev builds can
co-exist with the code for projects builds, the library should be
shared.

So the easiest way to solve that seems to be:
1) Create javacvs/libmodule folder, where the build.xml and manifest
   for the library autoload module will be stored. The build script
   will build just javacvs/libsrc/* package. Everything outside of
   javacvs/libmodule will remain intact and therefore the javacvs
   module will stay in dev builds as it is.
2) Add javacvs/libmodule to the main build script of the projects
   build.
3) Create a dependency of cvs-profile module on the new cvslib
   autoload module.
4) There will be a new sub-component in Issuezilla "library".

I'm going to finally implement this proposal shortly...

Done.
* javacvs/libmodule is there with it's own build script and manifest,
* library subcomponent is there - I'll move the apropriate issues,
* javacvs/libmodule was added to the projects build thanks to Vita,
* cvs-profile module has a dependency on javacvs/libmodule

I've verified on actual netbeans TRUNK sources by:
cd .../nb_all/javacvs/libmodule/; ant

and .../netbeans/modules/autoload/cvslib.jar
was builded which is a part of project nb build.