I noticed in the source code for the CVS task, this comment:
// XXX: we should use JCVS (www.ice.com/JCVS) instead of
// command line execution so that we don't rely on having
// native CVS stuff around (SM)
// We can't do it ourselves as jCVS is GPLed, a third party task
// outside of jakarta repositories would be possible though (SB).
Which makes perfect sense. Even LGPL would have problems being linked too
with java's import statement.
(http://issues.apache.org/wiki/apachewiki.cgi?Licensing)
Recently the idea of having a native java interface to cvs instead of
shelling out to CVS came up on the Maven development list
(http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
&by=thread&from=518930)
The NetBeans project was brought up, and javacvs in particular.
http://javacvs.netbeans.org/library/index.html
Since this is licensed under the Sun Public License
(http://www.netbeans.org/about/legal/license.html) which someone said is
compatible with the Apache License.
Now I know we can't just up and replace the current <cvs> task for backwards
compatibility (since we are never going to fully implement every possible
command combination). Maybe we can make a new optional task (<javacvs>),
since we have to link to something under the Sun Public License, and can't
re-distribute the jar file.
I don't know enough Java to tackle this myself, but thought I would start a
discussion and see who else is interested in a native java cvs task. (I've
seen it come up a few times on here, at least once that I can remember for
sure).
-- Larry
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
