OK. I found a way that isn't quite so ugly. I moved all the code that references the new class in commons-net off to a separate compilation unit, a new class in the org.apache.tools.ant.taskdefs.optional.net package. Now there are no issues with bad import statements in the FTP class itself.Steve Cohen wrote:
Nope, spoke too soon. I wasn't running against what I thought I was.Stefan Bodewig wrote:
On 12 May 2005, <[EMAIL PROTECTED]> wrote:
+ For all users, a minimum version of commons-net of 1.4.0 is now required.
Is this really true?
I understand it is required to compile <ftp> or if you use one of the new features. But if you use <ftp> the same way you did before and use a binary installation of Ant, 1.2.x should work as well, not?
Stefan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
You are correct, sir. It won't compile but it will run against the older jar, as long as the new functionalities are not called. I forget that not everyone wants to build ant :-).
The existing tests can be run successfully if you ignore the errors. You see, Antoine, your tests have already proven their value!
I will revise this documentation, and also change the code to output a more meaningful error message if anyone tries to use the new features with an older jar.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
With commons-net-1.2.2 jar, the bad import statement makes the test constructor throw.
This is so ugly.
I wonder if I could do a Class.forName(), and if it doesn't throw, I know I can use reflection to do the new stuff, and avoid importing the new class.
This is so ugly.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Since the new class is in the same package as FTP.java it doesn't need to be imported in order to compile. The new class isn't referenced unless the right commons-net version is present.
As long as the new code isn't called, there is no problem when using older versions of commons-net. Otherwise, a BuildException is thrown.
I don't know, though, guys. What do you think? Is it really worth it to avoid making the users upgrade?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
