commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <...@savarese.org>
Subject Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Date Fri, 02 Jan 2004 19:00:02 GMT

In message <200401010816.13592.scohen@javactivity.org>, steve cohen writes:
>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.

+1; same as Jeffrey suggested.

>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?

+1 to fixing all 1.1 incompatibilities before branching.  I skipped ahead
in the thread and see Jeffrey already answered how to run compile for
1.1 with Maven.

>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 

If there really isn't a need, don't do it.  I just thought users may
need to be able to customize the method used to determine which parser
is returned.  I thought it would become an issue when you started
writing code that created parsers using the static factory method.

>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?

I figured an automatic detector would accept a parser factory as an
argument in either a constructor or detection method.  The default
constructor or default no-argument method would use a default
implementation (whatever you were writing for the static method).
That users could provide their own factories for systems we haven't
anticipated.  Probably they'd just subclass the default implementation,
override the factory method, provide their own detection code for the
systems they care about that we don't handle, and delegate to the
superclass method anything else.  Alternatively, there may be situations
where they want to implement something from scratch, in which case they
would just implement the interface.

daniel



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message