>>>>> On Thu, 01 Jan 2004 08:16:13 -0600, steve cohen <[EMAIL PROTECTED]> said:
> Seems to me the HashMap ---> Hashtable change could be made against > HEAD. It's only NECESSARY for 1.1 compatibility but it poses no > great problem for a 1.2 compatible version; it isn't as if this > would impact some functionality deep in the core of the product. So > after this is done, a NET_1_1_1 tag could be created and that could > be the final of this branch. This sounds like a good idea. Make the 1.1 compatibility on HEAD, tag, and if need be branch from that tag point for 1.1 fixes. > On the other hand, if there are other 1.1 incompatibilities we may > want to fix those too, and then this might get a little > problematical. Hey, Jeffrey, do you know if there's an easy way to > make Maven do a JDK 1.1 compile? Or would it be easier to just > tinker with the generated ant script? Maven uses the following property: maven.compiler.target which defaults to 1.1 so what I last released generated 1.1 compatible class files. http://maven.apache.org/reference/plugins/java/properties.html Example: maven -Dmaven.compiler.target=1.2 clean jar > On the subject of the pluggable parser factory, I'm not sure I see > the need, but it's easy enough to do it that way, so I will make the > change. Am I correct in assuming that in your plan there would be a > default implementation, with other factories being selectable > instead on the basis of a property? > On Wednesday 31 December 2003 10:42 pm, Daniel F. Savarese wrote: >> In message <[EMAIL PROTECTED]>, steve cohen >> writes: >I am not completely CVS-literate and setting up the >> branches is beyond my >current level of experience but probably >> would be good experience for me. >> >> In my response to Jeffrey's email, I asked about whether we wanted >> to replace the existing NET_1_1_0 tag with a new NET_1_1_0 branch >> tag or leave the existing tag alone and attach a special branch tag >> with a different name to the NET_1_1_0 files. After we resolve >> that, if you want to do it, go ahead. I don't know if you can use >> the -F and -b options together with cvs tag, which is why I >> suggested the roundabout way of renaming the tag and creating a new >> one with the old name using -b. Subversion makes this easier. >> >> >without requiring it to have far more knowledge of commons-net >> internals > than I think is healthy. So I am developing an >> FTPFileEntryParserFactory > and some convenience methods in >> FTPClient to enable Ant to be recoded > decently. >> >> I followed the emails. Sounds great. I forgot to offer a comment. >> I was going to suggest making FTPFileEntryParserFactory either a >> class or an interface that has to be instantiated rather than a >> singleton. I think you were intending to make >> createFileEntryParser a static method. I suggest the use of an >> interface and a default factory class for the same reason we had to >> write SocketFactory and much later, in J2SE 1.4, Sun added its own >> javax.net.SocketFactory and javax.net.ServerSocketFactory. It >> allows generic code to be written that accepts pluggable parser >> factories should a user decide to implement his own factory. I'm >> thinking about the automatic detection code you alluded to, which >> could then be configurable/extensible through the insertion of >> parser factories. >> >> >I can also make the HashMap-->Hashtable change for the 1.1.1 >> branch. The > JDK 1.1 incompatibility was DISCOVERED through >> failure of the unit test > but the offending code is in the class >> being tested, not the test itself. > I have >> >> Sure thing. Let's decide how to tag that branch. >> >> >And it sounds like you have an itch for doing the nio stuff. >> >> It's been nagging me for a while, but I'm actually writing >> networking code these days based on java.nio, so I figure I should >> kill two birds with one stone and start rolling it into Commons Net >> as a proposal instead of keeping it in my private library. It's so >> much easier to dedicate volunteer committer hours when you're >> working on/using the stuff anyway. >> >> daniel >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: >> [EMAIL PROTECTED] > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- ===================================================================== Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
