From the Change Log section on their website http://jline.sourceforge.net/
0.9.0 2005-01-23 - Changed license from GPL to BSD. -Donald Kevan Miller wrote:
On Apr 19, 2007, at 9:35 AM, Aaron Mulder wrote:On 4/19/07, Ted Kirby <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:I am uncomfortable with what feels to me like an architectural deviation. It would seem that an AG goal is portability to many platforms. This seems implicit with java, and certainly depends on java being supported on many platforms. By using JLine, we are letting that package determine on which platforms AG will run. I would feel more comfortable with this decision if JLine were an Apache project. Going forward with JLine raises the barrier of entry for a platform to support Geronimo: it must insure that JLine runs on it, with possible native code required. Is this something we really want to do?I'm not following your logic. According to the documentation, on platforms where JLine does not have a native library, it uses essentially the same code we used to use. So it doesn't seem to me that there really are any portability limitations. It may "work better" on certain platforms (that is, no possibility of password characters appearing on the command line), but on all other platforms, the behavior is no worse than before (that is, we try hard to wipe out password characters, but the occasional one shows up briefly). Still, back to the original issue, if there is some problem with where we set the tempdir for various configurations (and therefore how JLine deals with the native libraries), we should fix that.Agreed. IIRC, we had a similar discussion when JLine was first introduced into Geronimo. I'm comfortable with JLine. If there are explicit issues, which we aren't recognizing, please let us know...--kevan
smime.p7s
Description: S/MIME Cryptographic Signature
