You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Daniel F. Savarese" <df...@savarese.org> on 2004/01/01 05:42:18 UTC
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
In message <20...@javactivity.org>, 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Posted by steve cohen <sc...@javactivity.org>.
Yes, in order to verify that the code doesn't use any 1.2+ code I found that
you have to also use bootclasspath={path to jdk1.1.8 classes.zip}
There were a couple of other instances:
use of ArrayLists in VMSFTPEntryParser and in ExtendedNNTPOps.java
in the examples section.
I cleaned all of these up and committed them. In the case of the ArrayList in
VMSFTPEntryParser, it did not work to change the file container to a Vector.
This code was calling a method in ORO that returned a Collection, also not
JDK1.1 compatible. Since the older ORO method that returned a Vector had
been deprecated, I looked at what it was doing, which was simply splitting a
string on a comma. This was an overkill use of ORO, easily replicated with a
StringTokenizer.
Talk about a stroll down memory lane!
On Thursday 01 January 2004 02:18 pm, Jeffrey D. Brekke wrote:
> I believe it just produces 1.1 compatible class files. Maven just
> passes the setting to the ant task, which passes it to javac. Since
> the HashMap class is is not present under 1.1 I guess we'd just get a
> ClassNotFoundException.
>
> I believe that should be all we need, we shouldn't need to *compile*
> with the javac from 1.1, we just need to use classes that are present
> with 1.1 and produce 1.1 compatible classes ( byte codes ).
>
> >>>>> On Thu, 01 Jan 2004 10:57:24 -0600, steve cohen
> >>>>> <sc...@javactivity.org> said:
> >
> > On Thursday 01 January 2004 09:06 am, Jeffrey D. Brekke wrote:
> >> 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
> >
> > Then I don't understand why I was able to build, since HashMap is
> > not in 1.1.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
I believe it just produces 1.1 compatible class files. Maven just
passes the setting to the ant task, which passes it to javac. Since
the HashMap class is is not present under 1.1 I guess we'd just get a
ClassNotFoundException.
I believe that should be all we need, we shouldn't need to *compile*
with the javac from 1.1, we just need to use classes that are present
with 1.1 and produce 1.1 compatible classes ( byte codes ).
>>>>> On Thu, 01 Jan 2004 10:57:24 -0600, steve cohen <sc...@javactivity.org> said:
> On Thursday 01 January 2004 09:06 am, Jeffrey D. Brekke wrote:
>> 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
>>
> Then I don't understand why I was able to build, since HashMap is
> not in 1.1.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Posted by di...@multitask.com.au.
It's not forcing the use of 1.1 code, just the 1.1 class file format.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
steve cohen <sc...@javactivity.org> wrote on 02/01/2004 03:57:24 AM:
> On Thursday 01 January 2004 09:06 am, Jeffrey D. Brekke wrote:
>
> > 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
> >
> Then I don't understand why I was able to build, since HashMap is not in
1.1.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Posted by steve cohen <sc...@javactivity.org>.
On Thursday 01 January 2004 09:06 am, Jeffrey D. Brekke wrote:
> 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
>
Then I don't understand why I was able to build, since HashMap is not in 1.1.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
>>>>> On Thu, 01 Jan 2004 08:16:13 -0600, steve cohen <sc...@javactivity.org> 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 <20...@javactivity.org>, 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> commons-dev-help@jakarta.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Posted by steve cohen <sc...@javactivity.org>.
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.
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?
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 <20...@javactivity.org>, 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org