You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Rory Winston <rw...@eircom.net> on 2006/09/08 18:47:11 UTC
[VOTE] Release [net] version 2.0
Hi all
I would like to gauge support for a release of Commons::Net 2.0. The
major changes are:
* FTPS (SSL/TLS) support has been added
* FTPClient doesnt extend TelnetClient any longer
* The build now uses Maven 2
* [net] is now standalone - no external dependencies outside the JDK itself
* One new FTP parser (Netware) has been added, and the MVS parser has
been heavily updated
* A mini "FTP-only" jar (~ 90k) is available for clients who just need
FTP functionality
* Deprecated classes and methods have been removed
A full list of changes can be found here:
http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html
I have made the distribution (*unsigned* as yet) available for inspection:
http://people.apache.org/~rwinston/commons-net-2.0/
And the site is available:
http://people.apache.org/~rwinston/commons-net-2.0/site/
Thanks
Rory
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VOTE] Release [net] version 2.0
Posted by Rahul Akolkar <ra...@gmail.com>.
On 9/9/06, Steve Cohen <sc...@javactivity.org> wrote:
<snip/>
>
> I am not ready to vote yet on this until there is a discussion about what this
> release means. Will commons-net-2.0 become the "official" release, with
> previous versions relegated to "backward compatibility" support? If so, this
> may be premature as Sun is still supporting JDK-1.4.2-x.
>
<snap/>
I see this has spawned the necessary discussion, and I'm unlikely to
vote until that discussion reaches some semblance of completion.
-Rahul
> But I don't think we should stand in the way of progress either. Rory, can you
> comment on what are the specific new features that demand JDK 5.0 support?
>
> How have other jakarta-commons projects handled this? Are there any official
> versions that require 1.5? Are there projects that have two "official" releases?
>
> Steve Cohen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Rahul Akolkar <ra...@gmail.com>.
On 9/10/06, Steve Cohen <sc...@javactivity.org> wrote:
> Continuing the discussion:
>
> 1. Regex support is in 1.4. It's only because we were trying to stay 1.2/1.3
> compatible that we couldn't use it. That's a small point. I doubt we want to
> have (say) a 1.4.2 branch that requires 1.4 after having supported 1.2/1.3 for
> all these years, if our soon-to-be target is 1.5. I do agree that the oro
> dependency has been a very annoying pebble in the shoe.
>
> 2. I'm not comfortable with the .net5 package name. I see a cvs nightmare down
> that road. I guess SVN can handle that but it's still ugly. It makes upgrade
> for clients of net a maintenance nightmare.
>
> 3. > JDK 5.0 has been officially released for around
> > two years. In my opinion, there shouldn't even be a debate. It should be
> > taken advantage of, and supported, although not at the expense of
> > existing users on older versions.
>
> No, there unfortunately does need to be this debate. Sun has not end-of-lifed
> 1.4.2. That is important. They continue to release new subreleases of 1.4.2.
> Why? Important clients are still not ready to use 5.0. My employer, a very
> large corporation, now mandates the use of 5.0 but is forced immediately to
> relent on this mandate for some of its most important projects because it also
> still uses a lot of Websphere which still does not support 5.0 (and won't until
> WebSphere 7 is released and even then it will be some time before the server
> teams are ready to make that switch - they dragged their feet on Websphere 6
> until recently). So Sun has to support 1.4 (and continues to have to make new
> subreleases of 1.4.2 for reasons such as the new daylight savings time start/end
> dates). The world marches on even when corporate java clients do not.
>
> Backward compatibility's a bitch, but if Sun has to worry about this, I think we
> do too. I don't think jakarta-commons has ever "downgraded" a version of java
> that Sun considers live.
>
> And yet, as Rory says, there are some compelling reasons to do so. I'd love to
> use JDK 5.0. It hasn't been a possibility for me yet. Even outside of work,
> for a long time Eclipse did not support 5.0 although I don't think it is anymore.
>
> So what is the solution? What does it mean to say "not at the expense of
> existing users on older versions?" I think we'd need to modify the site to have
> full support for two release branches, with some easy switch between them.
> There should be navigation menu items on the 2.0 site that point back to the
> 1.4.x site and vice versa as is the case with Tomcat and other projects. We
> can't just say all new development will be on 2.0, we'll continue to make 1.4.1
> available for those who can't make the move. We may want to say that, but I
> don't think our user base will let us. Until Sun EOL's 1.4.x, I think our
> policy must be that every change that can be supported on pre-2.0 will be
> supported there.
>
> I also wonder if this should be a jakarta-commons-wide policy and not just
> something that net does.
>
<snip/>
Mostly agree to Steve's note above. IMO:
* New projects have a choice to start off with 1.4 (the least version
that hasn't begun the EOL process) -- as did SCXML. Unless ofcourse,
the central concept of the component itself is based on a 1.5 (or
higher) feature.
* Older projects need to atleast support 1.4 (with active development
as in ports back from a 1.5 branch where possible etc.) until 1.4
begins to be EOL'ed. Again, above caveat will apply.
Having said that, I've been a proponent of 1.5 branches (and now
releases, as long as they're preceded by suitable discussion).
As a sidebar, Hen -- I feel your pain about having to go <=1.2 for
certain releases. Personally, I won't even think about RM'ing anything
that needs those. In the end, if its causing much grief that hampers
releases, perhaps that baseline may need revisiting.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release [net] version 2.0
Posted by Steve Cohen <sc...@javactivity.org>.
Thank you, Rory.
I'm now officially +1
Rory Winston wrote:
> Steve
>
> Sorry, I should have been more specific
>
> 1) Yes, there will be two separate branches of development. At the
> moment, the trunk is the 1.x branch, whereas there is a separate branch
> for JDK 5.0 dev. We can keep this the way it is, or swap the trunk and
> branch at some stage.
>
> 2) We need two sites, for sure. I think an easy way would be to do the
> separate Maven 1 (1.x codebase) and Maven 2.0 (2.x codebase) builds, and
> just put a link from one site to the other in the Maven menus.
> Otherwise, if Maven 2 can handle this kind of situation out of the box,
> we should move the 1.x build over to Maven 2 as well.What do you think?
>
> Hope this helps
> Rory
>
> Steve Cohen wrote:
>> Rory Winston wrote:
>>> OK, seeing as we have reached some kind of consensus on how to handle
>>> backards-incompatible JDK releases, I'm restarting the vote for a
>>> release of Commons::Net 2.0 (the JDK 5.0 branch).
>>>
>>> As per usual, just respond with
>>>
>>> +1
>>> +0
>>> -0
>>> -1
>>>
>>> Thanks
>>> Rory
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>> Sorry, Rory, but I think you need to express the consensus that you
>> think we are voting on. You haven't done that. "release of
>> Commons::Net 2.0 (the JDK 5.0 branch)" doesn't get to the heart of all
>> the issues.
>>
>> 1: Are there two "official" branches or is 1.4.x relegated to
>> "backward compatibility mode"? I would insist that there be two
>> branches until Sun puts 1.4.x into EndOfLife mode.
>>
>> 2. Is the site going to be organized to reflect the two branches?
>>
>> If those two points are part of your "motion", I'm +1. Otherwise, I'm
>> -1.
>>
>> Steve
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release [net] version 2.0
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Can you analyse which of the ERROR lines are the removal of deprecated
methods (the rest being specific incompatibilities). The INFO lines are
obviously fine.
thanks
Stephen
Rory Winston wrote:
> It seems to handle Java 5 ok ... it generated a report for me, at least.
>
> INFO: 8000: examples.FTPExample: Class examples.FTPExample added
> INFO: 8000: examples.FTPSExample: Class examples.FTPSExample added
> INFO: 8000: examples.IOUtil: Class examples.IOUtil added
> INFO: 8000: examples.NetClient: Class examples.NetClient added
> INFO: 8000: examples.TelnetClientExample: Class
> examples.TelnetClientExample added
> INFO: 8000: examples.chargen: Class examples.chargen added
> INFO: 8000: examples.daytime: Class examples.daytime added
> INFO: 8000: examples.echo: Class examples.echo added
> INFO: 8000: examples.finger: Class examples.finger added
> INFO: 8000: examples.fwhois: Class examples.fwhois added
> INFO: 8000: examples.mail: Class examples.mail added
> INFO: 8000: examples.messages: Class examples.messages added
> INFO: 8000: examples.nntp.ExtendedNNTPOps: Class
> examples.nntp.ExtendedNNTPOps added
> INFO: 8000: examples.nntp.MessageThreading: Class
> examples.nntp.MessageThreading added
> INFO: 8000: examples.nntp.NNTPUtils: Class examples.nntp.NNTPUtils added
> INFO: 8000: examples.nntp.newsgroups: Class examples.nntp.newsgroups added
> INFO: 8000: examples.nntp.post: Class examples.nntp.post added
> INFO: 8000: examples.ntp.NTPClient: Class examples.ntp.NTPClient added
> INFO: 8000: examples.ntp.TimeClient: Class examples.ntp.TimeClient added
> INFO: 8000: examples.rdate: Class examples.rdate added
> INFO: 8000: examples.rexec: Class examples.rexec added
> INFO: 8000: examples.rlogin: Class examples.rlogin added
> INFO: 8000: examples.rshell: Class examples.rshell added
> INFO: 8000: examples.server2serverFTP: Class examples.server2serverFTP
> added
> INFO: 8000: examples.tftp: Class examples.tftp added
> INFO: 8000: examples.weatherTelnet: Class examples.weatherTelnet added
> ERROR: 8001: org.apache.commons.net.CharGenTCPClient: Class
> org.apache.commons.net.CharGenTCPClient removed
> ERROR: 8001: org.apache.commons.net.CharGenUDPClient: Class
> org.apache.commons.net.CharGenUDPClient removed
> ERROR: 8001: org.apache.commons.net.DaytimeTCPClient: Class
> org.apache.commons.net.DaytimeTCPClient removed
> ERROR: 8001: org.apache.commons.net.DaytimeUDPClient: Class
> org.apache.commons.net.DaytimeUDPClient removed
> ERROR: 4001: org.apache.commons.net.DefaultSocketFactory: Removed
> org.apache.commons.net.SocketFactory from the set of implemented interfaces
> INFO: 5000: org.apache.commons.net.DefaultSocketFactory: Added
> javax.net.SocketFactory to the list of superclasses
> ERROR: 8001: org.apache.commons.net.DiscardTCPClient: Class
> org.apache.commons.net.DiscardTCPClient removed
> ERROR: 8001: org.apache.commons.net.DiscardUDPClient: Class
> org.apache.commons.net.DiscardUDPClient removed
> ERROR: 8001: org.apache.commons.net.EchoTCPClient: Class
> org.apache.commons.net.EchoTCPClient removed
> ERROR: 8001: org.apache.commons.net.EchoUDPClient: Class
> org.apache.commons.net.EchoUDPClient removed
> ERROR: 8001: org.apache.commons.net.FingerClient: Class
> org.apache.commons.net.FingerClient removed
> INFO: 8000: org.apache.commons.net.PrintCommandListener: Class
> org.apache.commons.net.PrintCommandListener added
> INFO: 6000: org.apache.commons.net.SocketClient: Added protected field
> _serverSocketFactory_
> ERROR: 6004: org.apache.commons.net.SocketClient: Changed type of field
> _socketFactory_ from org.apache.commons.net.SocketFactory to
> javax.net.SocketFactory
> INFO: 7011: org.apache.commons.net.SocketClient: Method 'public void
> setServerSocketFactory(javax.net.ServerSocketFactory)' has been added
> ERROR: 7005: org.apache.commons.net.SocketClient: Parameter 1 of 'public
> void setSocketFactory(org.apache.commons.net.SocketFactory)' has changed
> its type to javax.net.SocketFactory
> ERROR: 8001: org.apache.commons.net.SocketFactory: Class
> org.apache.commons.net.SocketFactory removed
> ERROR: 8001: org.apache.commons.net.TimeTCPClient: Class
> org.apache.commons.net.TimeTCPClient removed
> ERROR: 8001: org.apache.commons.net.TimeUDPClient: Class
> org.apache.commons.net.TimeUDPClient removed
> ERROR: 8001: org.apache.commons.net.WhoisClient: Class
> org.apache.commons.net.WhoisClient removed
> INFO: 8000: org.apache.commons.net.chargen.CharGenTCPClient: Class
> org.apache.commons.net.chargen.CharGenTCPClient added
> INFO: 8000: org.apache.commons.net.chargen.CharGenUDPClient: Class
> org.apache.commons.net.chargen.CharGenUDPClient added
> INFO: 8000: org.apache.commons.net.daytime.DaytimeTCPClient: Class
> org.apache.commons.net.daytime.DaytimeTCPClient added
> INFO: 8000: org.apache.commons.net.daytime.DaytimeUDPClient: Class
> org.apache.commons.net.daytime.DaytimeUDPClient added
> INFO: 8000: org.apache.commons.net.discard.DiscardTCPClient: Class
> org.apache.commons.net.discard.DiscardTCPClient added
> INFO: 8000: org.apache.commons.net.discard.DiscardUDPClient: Class
> org.apache.commons.net.discard.DiscardUDPClient added
> INFO: 8000: org.apache.commons.net.echo.EchoTCPClient: Class
> org.apache.commons.net.echo.EchoTCPClient added
> INFO: 8000: org.apache.commons.net.echo.EchoUDPClient: Class
> org.apache.commons.net.echo.EchoUDPClient added
> INFO: 8000: org.apache.commons.net.finger.FingerClient: Class
> org.apache.commons.net.finger.FingerClient added
> ERROR: 8001: org.apache.commons.net.ftp.DefaultFTPFileListParser: Class
> org.apache.commons.net.ftp.DefaultFTPFileListParser removed
> ERROR: 5001: org.apache.commons.net.ftp.FTP: Removed
> org.apache.commons.net.telnet.Telnet from the list of superclasses
> ERROR: 5001: org.apache.commons.net.ftp.FTP: Removed
> org.apache.commons.net.telnet.TelnetClient from the list of superclasses
> ERROR: 6011: org.apache.commons.net.ftp.FTP: Field IMAGE_FILE_TYPE has
> been removed, but it was previously a constant
> INFO: 6009: org.apache.commons.net.ftp.FTP: Accessibility of field
> _controlEncoding has been increased from package to protected
> INFO: 6009: org.apache.commons.net.ftp.FTP: Accessibility of field
> _newReplyString has been increased from package to protected
> INFO: 6009: org.apache.commons.net.ftp.FTP: Accessibility of field
> _replyCode has been increased from package to protected
> INFO: 6009: org.apache.commons.net.ftp.FTP: Accessibility of field
> _replyLines has been increased from package to protected
> INFO: 6009: org.apache.commons.net.ftp.FTP: Accessibility of field
> _replyString has been increased from package to protected
> ERROR: 5001: org.apache.commons.net.ftp.FTPClient: Removed
> org.apache.commons.net.telnet.Telnet from the list of superclasses
> ERROR: 5001: org.apache.commons.net.ftp.FTPClient: Removed
> org.apache.commons.net.telnet.TelnetClient from the list of superclasses
> ERROR: 7002: org.apache.commons.net.ftp.FTPClient: Method 'public
> org.apache.commons.net.ftp.FTPFileList
> createFileList(org.apache.commons.net.ftp.FTPFileEntryParser)' has been
> removed
> ERROR: 7002: org.apache.commons.net.ftp.FTPClient: Method 'public
> org.apache.commons.net.ftp.FTPFileList createFileList(java.lang.String,
> org.apache.commons.net.ftp.FTPFileEntryParser)' has been removed
> INFO: 7011: org.apache.commons.net.ftp.FTPClient: Method 'protected
> java.lang.String getListArguments(java.lang.String)' has been added
> INFO: 7011: org.apache.commons.net.ftp.FTPClient: Method 'public boolean
> getListHiddenFiles()' has been added
> ERROR: 7002: org.apache.commons.net.ftp.FTPClient: Method 'public
> org.apache.commons.net.ftp.FTPFile[]
> listFiles(org.apache.commons.net.ftp.FTPFileListParser,
> java.lang.String)' has been removed
> ERROR: 7002: org.apache.commons.net.ftp.FTPClient: Method 'public
> org.apache.commons.net.ftp.FTPFile[]
> listFiles(org.apache.commons.net.ftp.FTPFileListParser)' has been removed
> INFO: 7011: org.apache.commons.net.ftp.FTPClient: Method 'public void
> setListHiddenFiles(boolean)' has been added
> ERROR: 4001: org.apache.commons.net.ftp.FTPFileEntryParserImpl: Removed
> org.apache.commons.net.ftp.FTPFileListParser from the set of implemented
> interfaces
> ERROR: 8001: org.apache.commons.net.ftp.FTPFileListParser: Class
> org.apache.commons.net.ftp.FTPFileListParser removed
> ERROR: 8001: org.apache.commons.net.ftp.FTPFileListParserImpl: Class
> org.apache.commons.net.ftp.FTPFileListParserImpl removed
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> CODE_234
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> CODE_235
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> CODE_334
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> CODE_335
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> CODE_431
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> CODE_533
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> CODE_534
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> CODE_535
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> CODE_536
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> DENIED_FOR_POLICY_REASONS
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> FAILED_SECURITY_CHECK
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> REQUESTED_PROT_LEVEL_NOT_SUPPORTED
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> REQUEST_DENIED
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> SECURITY_DATA_EXCHANGE_COMPLETE
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> SECURITY_DATA_EXCHANGE_SUCCESSFULLY
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> SECURITY_DATA_IS_ACCEPTABLE
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> SECURITY_MECHANISM_IS_OK
> INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
> UNAVAILABLE_RESOURCE
> INFO: 8000: org.apache.commons.net.ftp.FTPSClient: Class
> org.apache.commons.net.ftp.FTPSClient added
> INFO: 8000: org.apache.commons.net.ftp.FTPSCommand: Class
> org.apache.commons.net.ftp.FTPSCommand added
> INFO: 8000: org.apache.commons.net.ftp.FTPSSocketFactory: Class
> org.apache.commons.net.ftp.FTPSSocketFactory added
> INFO: 8000: org.apache.commons.net.ftp.FTPSTrustManager: Class
> org.apache.commons.net.ftp.FTPSTrustManager added
> ERROR: 4001: org.apache.commons.net.ftp.parser.CompositeFileEntryParser:
> Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
> implemented interfaces
> ERROR: 4001:
> org.apache.commons.net.ftp.parser.ConfigurableFTPFileEntryParserImpl:
> Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
> implemented interfaces
> ERROR: 4001:
> org.apache.commons.net.ftp.parser.EnterpriseUnixFTPEntryParser: Removed
> org.apache.commons.net.ftp.FTPFileListParser from the set of implemented
> interfaces
> ERROR: 4001: org.apache.commons.net.ftp.parser.MVSFTPEntryParser:
> Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
> implemented interfaces
> INFO: 7011: org.apache.commons.net.ftp.parser.MVSFTPEntryParser: Method
> 'public java.util.List preParse(java.util.List)' has been added
> ERROR: 4001: org.apache.commons.net.ftp.parser.NTFTPEntryParser: Removed
> org.apache.commons.net.ftp.FTPFileListParser from the set of implemented
> interfaces
> ERROR: 4001: org.apache.commons.net.ftp.parser.NetwareFTPEntryParser:
> Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
> implemented interfaces
> ERROR: 4001: org.apache.commons.net.ftp.parser.OS2FTPEntryParser:
> Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
> implemented interfaces
> ERROR: 4001: org.apache.commons.net.ftp.parser.OS400FTPEntryParser:
> Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
> implemented interfaces
> ERROR: 4001:
> org.apache.commons.net.ftp.parser.RegexFTPFileEntryParserImpl: Removed
> org.apache.commons.net.ftp.FTPFileListParser from the set of implemented
> interfaces
> ERROR: 6004:
> org.apache.commons.net.ftp.parser.RegexFTPFileEntryParserImpl: Changed
> type of field _matcher_ from org.apache.oro.text.regex.PatternMatcher to
> java.util.regex.Matcher
> INFO: 7011:
> org.apache.commons.net.ftp.parser.RegexFTPFileEntryParserImpl: Method
> 'public boolean setRegex(java.lang.String)' has been added
> ERROR: 4001: org.apache.commons.net.ftp.parser.UnixFTPEntryParser:
> Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
> implemented interfaces
> ERROR: 4001: org.apache.commons.net.ftp.parser.VMSFTPEntryParser:
> Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
> implemented interfaces
> ERROR: 4001:
> org.apache.commons.net.ftp.parser.VMSVersioningFTPEntryParser: Removed
> org.apache.commons.net.ftp.FTPFileListParser from the set of implemented
> interfaces
> INFO: 8000: org.apache.commons.net.telnet.WindowSizeOptionHandler: Class
> org.apache.commons.net.telnet.WindowSizeOptionHandler added
> INFO: 8000: org.apache.commons.net.time.TimeTCPClient: Class
> org.apache.commons.net.time.TimeTCPClient added
> INFO: 8000: org.apache.commons.net.time.TimeUDPClient: Class
> org.apache.commons.net.time.TimeUDPClient added
> INFO: 4000: org.apache.commons.net.util.ListenerList: Added
> java.lang.Iterable to the set of implemented interfaces
> ERROR: 7002: org.apache.commons.net.util.ListenerList: Method 'public
> java.util.Enumeration getListeners()' has been removed
> INFO: 7011: org.apache.commons.net.util.ListenerList: Method 'public
> java.util.Iterator iterator()' has been added
> INFO: 8000: org.apache.commons.net.whois.WhoisClient: Class
> org.apache.commons.net.whois.WhoisClient added
>
>
> Simon Kitching wrote:
>
>> Sorry, text and xml are the only clirr formats supported as far as I
>> know (last time I looked). The text output is fairly readable though not
>> pretty I agree.
>>
>> I'm not sure how well clirr handles java 1.5.
>>
>> Cheers,
>>
>> Simon
>>
>> On Wed, 2006-09-13 at 11:14 +0100, Rory Winston wrote:
>>
>>
>>> Sure,
>>>
>>> I can output a clirr report in text or xml, is there any predefined
>>> templates to convert it to a more readable format (i.e. HTML)?
>>>
>>> Rory
>>>
>>>
>>> Stephen Colebourne wrote:
>>>
>>>
>>>> Perhaps you could run a clirr report, and publish the result? That
>>>> way we can all see what the amount of change in the API is.
>>>>
>>>> And yes, this cold potentially be a problem with any non
>>>> backwards-compatible release. As I said before, I'm driving to find
>>>> out how this release will sit within the wider OSS and user
>>>> community, and to try and avoid jar-hell.
>>>>
>>>> Stephen
>>>>
>>>> ----- Original Message ----
>>>> From: Rory Winston <rw...@eircom.net>
>>>> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>>>> Sent: Wednesday, 13 September, 2006 8:53:27 AM
>>>> Subject: Re: [VOTE] Release [net] version 2.0
>>>>
>>>> Stephen
>>>>
>>>> I'm afraid I dont really get waht you're asking? Surely this would
>>>> be a problem with any project that produces a
>>>> non-backwards-compatible release? As for the API, it is 99%
>>>> backwards compatible - so far, there are little changes to the
>>>> public interface.
>>>>
>>>> Stephen Colebourne wrote:
>>>>
>>>>
>>>>> My question is whether 2.0 is backwards compatible with 1.0. If it
>>>>> isn't, then how are we going to handle the situation where two
>>>>> different OSS projects refer to two different versions of [net] -
>>>>> jar-hell.
>>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>> Rory Winston wrote:
>>>>>
>>>>>
>>>>>> Steve
>>>>>>
>>>>>> Sorry, I should have been more specific
>>>>>>
>>>>>> 1) Yes, there will be two separate branches of development. At the
>>>>>> moment, the trunk is the 1.x branch, whereas there is a separate
>>>>>> branch for JDK 5.0 dev. We can keep this the way it is, or swap
>>>>>> the trunk and branch at some stage.
>>>>>>
>>>>>> 2) We need two sites, for sure. I think an easy way would be to do
>>>>>> the separate Maven 1 (1.x codebase) and Maven 2.0 (2.x codebase)
>>>>>> builds, and just put a link from one site to the other in the
>>>>>> Maven menus. Otherwise, if Maven 2 can handle this kind of
>>>>>> situation out of the box, we should move the 1.x build over to
>>>>>> Maven 2 as well.What do you think?
>>>>>>
>>>>>> Hope this helps
>>>>>> Rory
>>>>>>
>>>>>> Steve Cohen wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Rory Winston wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> OK, seeing as we have reached some kind of consensus on how to
>>>>>>>> handle backards-incompatible JDK releases, I'm restarting the
>>>>>>>> vote for a release of Commons::Net 2.0 (the JDK 5.0 branch).
>>>>>>>>
>>>>>>>> As per usual, just respond with
>>>>>>>>
>>>>>>>> +1
>>>>>>>> +0
>>>>>>>> -0
>>>>>>>> -1
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Rory
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>>>>> For additional commands, e-mail:
>>>>>>>> commons-dev-help@jakarta.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Sorry, Rory, but I think you need to express the consensus that
>>>>>>> you think we are voting on. You haven't done that. "release of
>>>>>>> Commons::Net 2.0 (the JDK 5.0 branch)" doesn't get to the heart
>>>>>>> of all the issues.
>>>>>>>
>>>>>>> 1: Are there two "official" branches or is 1.4.x relegated to
>>>>>>> "backward compatibility mode"? I would insist that there be two
>>>>>>> branches until Sun puts 1.4.x into EndOfLife mode.
>>>>>>>
>>>>>>> 2. Is the site going to be organized to reflect the two branches?
>>>>>>>
>>>>>>> If those two points are part of your "motion", I'm +1.
>>>>>>> Otherwise, I'm -1.
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release [net] version 2.0
Posted by Rory Winston <rw...@eircom.net>.
It seems to handle Java 5 ok ... it generated a report for me, at least.
INFO: 8000: examples.FTPExample: Class examples.FTPExample added
INFO: 8000: examples.FTPSExample: Class examples.FTPSExample added
INFO: 8000: examples.IOUtil: Class examples.IOUtil added
INFO: 8000: examples.NetClient: Class examples.NetClient added
INFO: 8000: examples.TelnetClientExample: Class
examples.TelnetClientExample added
INFO: 8000: examples.chargen: Class examples.chargen added
INFO: 8000: examples.daytime: Class examples.daytime added
INFO: 8000: examples.echo: Class examples.echo added
INFO: 8000: examples.finger: Class examples.finger added
INFO: 8000: examples.fwhois: Class examples.fwhois added
INFO: 8000: examples.mail: Class examples.mail added
INFO: 8000: examples.messages: Class examples.messages added
INFO: 8000: examples.nntp.ExtendedNNTPOps: Class
examples.nntp.ExtendedNNTPOps added
INFO: 8000: examples.nntp.MessageThreading: Class
examples.nntp.MessageThreading added
INFO: 8000: examples.nntp.NNTPUtils: Class examples.nntp.NNTPUtils added
INFO: 8000: examples.nntp.newsgroups: Class examples.nntp.newsgroups added
INFO: 8000: examples.nntp.post: Class examples.nntp.post added
INFO: 8000: examples.ntp.NTPClient: Class examples.ntp.NTPClient added
INFO: 8000: examples.ntp.TimeClient: Class examples.ntp.TimeClient added
INFO: 8000: examples.rdate: Class examples.rdate added
INFO: 8000: examples.rexec: Class examples.rexec added
INFO: 8000: examples.rlogin: Class examples.rlogin added
INFO: 8000: examples.rshell: Class examples.rshell added
INFO: 8000: examples.server2serverFTP: Class examples.server2serverFTP added
INFO: 8000: examples.tftp: Class examples.tftp added
INFO: 8000: examples.weatherTelnet: Class examples.weatherTelnet added
ERROR: 8001: org.apache.commons.net.CharGenTCPClient: Class
org.apache.commons.net.CharGenTCPClient removed
ERROR: 8001: org.apache.commons.net.CharGenUDPClient: Class
org.apache.commons.net.CharGenUDPClient removed
ERROR: 8001: org.apache.commons.net.DaytimeTCPClient: Class
org.apache.commons.net.DaytimeTCPClient removed
ERROR: 8001: org.apache.commons.net.DaytimeUDPClient: Class
org.apache.commons.net.DaytimeUDPClient removed
ERROR: 4001: org.apache.commons.net.DefaultSocketFactory: Removed
org.apache.commons.net.SocketFactory from the set of implemented interfaces
INFO: 5000: org.apache.commons.net.DefaultSocketFactory: Added
javax.net.SocketFactory to the list of superclasses
ERROR: 8001: org.apache.commons.net.DiscardTCPClient: Class
org.apache.commons.net.DiscardTCPClient removed
ERROR: 8001: org.apache.commons.net.DiscardUDPClient: Class
org.apache.commons.net.DiscardUDPClient removed
ERROR: 8001: org.apache.commons.net.EchoTCPClient: Class
org.apache.commons.net.EchoTCPClient removed
ERROR: 8001: org.apache.commons.net.EchoUDPClient: Class
org.apache.commons.net.EchoUDPClient removed
ERROR: 8001: org.apache.commons.net.FingerClient: Class
org.apache.commons.net.FingerClient removed
INFO: 8000: org.apache.commons.net.PrintCommandListener: Class
org.apache.commons.net.PrintCommandListener added
INFO: 6000: org.apache.commons.net.SocketClient: Added protected field
_serverSocketFactory_
ERROR: 6004: org.apache.commons.net.SocketClient: Changed type of field
_socketFactory_ from org.apache.commons.net.SocketFactory to
javax.net.SocketFactory
INFO: 7011: org.apache.commons.net.SocketClient: Method 'public void
setServerSocketFactory(javax.net.ServerSocketFactory)' has been added
ERROR: 7005: org.apache.commons.net.SocketClient: Parameter 1 of 'public
void setSocketFactory(org.apache.commons.net.SocketFactory)' has changed
its type to javax.net.SocketFactory
ERROR: 8001: org.apache.commons.net.SocketFactory: Class
org.apache.commons.net.SocketFactory removed
ERROR: 8001: org.apache.commons.net.TimeTCPClient: Class
org.apache.commons.net.TimeTCPClient removed
ERROR: 8001: org.apache.commons.net.TimeUDPClient: Class
org.apache.commons.net.TimeUDPClient removed
ERROR: 8001: org.apache.commons.net.WhoisClient: Class
org.apache.commons.net.WhoisClient removed
INFO: 8000: org.apache.commons.net.chargen.CharGenTCPClient: Class
org.apache.commons.net.chargen.CharGenTCPClient added
INFO: 8000: org.apache.commons.net.chargen.CharGenUDPClient: Class
org.apache.commons.net.chargen.CharGenUDPClient added
INFO: 8000: org.apache.commons.net.daytime.DaytimeTCPClient: Class
org.apache.commons.net.daytime.DaytimeTCPClient added
INFO: 8000: org.apache.commons.net.daytime.DaytimeUDPClient: Class
org.apache.commons.net.daytime.DaytimeUDPClient added
INFO: 8000: org.apache.commons.net.discard.DiscardTCPClient: Class
org.apache.commons.net.discard.DiscardTCPClient added
INFO: 8000: org.apache.commons.net.discard.DiscardUDPClient: Class
org.apache.commons.net.discard.DiscardUDPClient added
INFO: 8000: org.apache.commons.net.echo.EchoTCPClient: Class
org.apache.commons.net.echo.EchoTCPClient added
INFO: 8000: org.apache.commons.net.echo.EchoUDPClient: Class
org.apache.commons.net.echo.EchoUDPClient added
INFO: 8000: org.apache.commons.net.finger.FingerClient: Class
org.apache.commons.net.finger.FingerClient added
ERROR: 8001: org.apache.commons.net.ftp.DefaultFTPFileListParser: Class
org.apache.commons.net.ftp.DefaultFTPFileListParser removed
ERROR: 5001: org.apache.commons.net.ftp.FTP: Removed
org.apache.commons.net.telnet.Telnet from the list of superclasses
ERROR: 5001: org.apache.commons.net.ftp.FTP: Removed
org.apache.commons.net.telnet.TelnetClient from the list of superclasses
ERROR: 6011: org.apache.commons.net.ftp.FTP: Field IMAGE_FILE_TYPE has
been removed, but it was previously a constant
INFO: 6009: org.apache.commons.net.ftp.FTP: Accessibility of field
_controlEncoding has been increased from package to protected
INFO: 6009: org.apache.commons.net.ftp.FTP: Accessibility of field
_newReplyString has been increased from package to protected
INFO: 6009: org.apache.commons.net.ftp.FTP: Accessibility of field
_replyCode has been increased from package to protected
INFO: 6009: org.apache.commons.net.ftp.FTP: Accessibility of field
_replyLines has been increased from package to protected
INFO: 6009: org.apache.commons.net.ftp.FTP: Accessibility of field
_replyString has been increased from package to protected
ERROR: 5001: org.apache.commons.net.ftp.FTPClient: Removed
org.apache.commons.net.telnet.Telnet from the list of superclasses
ERROR: 5001: org.apache.commons.net.ftp.FTPClient: Removed
org.apache.commons.net.telnet.TelnetClient from the list of superclasses
ERROR: 7002: org.apache.commons.net.ftp.FTPClient: Method 'public
org.apache.commons.net.ftp.FTPFileList
createFileList(org.apache.commons.net.ftp.FTPFileEntryParser)' has been
removed
ERROR: 7002: org.apache.commons.net.ftp.FTPClient: Method 'public
org.apache.commons.net.ftp.FTPFileList createFileList(java.lang.String,
org.apache.commons.net.ftp.FTPFileEntryParser)' has been removed
INFO: 7011: org.apache.commons.net.ftp.FTPClient: Method 'protected
java.lang.String getListArguments(java.lang.String)' has been added
INFO: 7011: org.apache.commons.net.ftp.FTPClient: Method 'public boolean
getListHiddenFiles()' has been added
ERROR: 7002: org.apache.commons.net.ftp.FTPClient: Method 'public
org.apache.commons.net.ftp.FTPFile[]
listFiles(org.apache.commons.net.ftp.FTPFileListParser,
java.lang.String)' has been removed
ERROR: 7002: org.apache.commons.net.ftp.FTPClient: Method 'public
org.apache.commons.net.ftp.FTPFile[]
listFiles(org.apache.commons.net.ftp.FTPFileListParser)' has been removed
INFO: 7011: org.apache.commons.net.ftp.FTPClient: Method 'public void
setListHiddenFiles(boolean)' has been added
ERROR: 4001: org.apache.commons.net.ftp.FTPFileEntryParserImpl: Removed
org.apache.commons.net.ftp.FTPFileListParser from the set of implemented
interfaces
ERROR: 8001: org.apache.commons.net.ftp.FTPFileListParser: Class
org.apache.commons.net.ftp.FTPFileListParser removed
ERROR: 8001: org.apache.commons.net.ftp.FTPFileListParserImpl: Class
org.apache.commons.net.ftp.FTPFileListParserImpl removed
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field CODE_234
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field CODE_235
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field CODE_334
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field CODE_335
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field CODE_431
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field CODE_533
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field CODE_534
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field CODE_535
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field CODE_536
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
DENIED_FOR_POLICY_REASONS
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
FAILED_SECURITY_CHECK
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
REQUESTED_PROT_LEVEL_NOT_SUPPORTED
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
REQUEST_DENIED
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
SECURITY_DATA_EXCHANGE_COMPLETE
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
SECURITY_DATA_EXCHANGE_SUCCESSFULLY
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
SECURITY_DATA_IS_ACCEPTABLE
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
SECURITY_MECHANISM_IS_OK
INFO: 6000: org.apache.commons.net.ftp.FTPReply: Added public field
UNAVAILABLE_RESOURCE
INFO: 8000: org.apache.commons.net.ftp.FTPSClient: Class
org.apache.commons.net.ftp.FTPSClient added
INFO: 8000: org.apache.commons.net.ftp.FTPSCommand: Class
org.apache.commons.net.ftp.FTPSCommand added
INFO: 8000: org.apache.commons.net.ftp.FTPSSocketFactory: Class
org.apache.commons.net.ftp.FTPSSocketFactory added
INFO: 8000: org.apache.commons.net.ftp.FTPSTrustManager: Class
org.apache.commons.net.ftp.FTPSTrustManager added
ERROR: 4001: org.apache.commons.net.ftp.parser.CompositeFileEntryParser:
Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
implemented interfaces
ERROR: 4001:
org.apache.commons.net.ftp.parser.ConfigurableFTPFileEntryParserImpl:
Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
implemented interfaces
ERROR: 4001:
org.apache.commons.net.ftp.parser.EnterpriseUnixFTPEntryParser: Removed
org.apache.commons.net.ftp.FTPFileListParser from the set of implemented
interfaces
ERROR: 4001: org.apache.commons.net.ftp.parser.MVSFTPEntryParser:
Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
implemented interfaces
INFO: 7011: org.apache.commons.net.ftp.parser.MVSFTPEntryParser: Method
'public java.util.List preParse(java.util.List)' has been added
ERROR: 4001: org.apache.commons.net.ftp.parser.NTFTPEntryParser: Removed
org.apache.commons.net.ftp.FTPFileListParser from the set of implemented
interfaces
ERROR: 4001: org.apache.commons.net.ftp.parser.NetwareFTPEntryParser:
Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
implemented interfaces
ERROR: 4001: org.apache.commons.net.ftp.parser.OS2FTPEntryParser:
Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
implemented interfaces
ERROR: 4001: org.apache.commons.net.ftp.parser.OS400FTPEntryParser:
Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
implemented interfaces
ERROR: 4001:
org.apache.commons.net.ftp.parser.RegexFTPFileEntryParserImpl: Removed
org.apache.commons.net.ftp.FTPFileListParser from the set of implemented
interfaces
ERROR: 6004:
org.apache.commons.net.ftp.parser.RegexFTPFileEntryParserImpl: Changed
type of field _matcher_ from org.apache.oro.text.regex.PatternMatcher to
java.util.regex.Matcher
INFO: 7011:
org.apache.commons.net.ftp.parser.RegexFTPFileEntryParserImpl: Method
'public boolean setRegex(java.lang.String)' has been added
ERROR: 4001: org.apache.commons.net.ftp.parser.UnixFTPEntryParser:
Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
implemented interfaces
ERROR: 4001: org.apache.commons.net.ftp.parser.VMSFTPEntryParser:
Removed org.apache.commons.net.ftp.FTPFileListParser from the set of
implemented interfaces
ERROR: 4001:
org.apache.commons.net.ftp.parser.VMSVersioningFTPEntryParser: Removed
org.apache.commons.net.ftp.FTPFileListParser from the set of implemented
interfaces
INFO: 8000: org.apache.commons.net.telnet.WindowSizeOptionHandler: Class
org.apache.commons.net.telnet.WindowSizeOptionHandler added
INFO: 8000: org.apache.commons.net.time.TimeTCPClient: Class
org.apache.commons.net.time.TimeTCPClient added
INFO: 8000: org.apache.commons.net.time.TimeUDPClient: Class
org.apache.commons.net.time.TimeUDPClient added
INFO: 4000: org.apache.commons.net.util.ListenerList: Added
java.lang.Iterable to the set of implemented interfaces
ERROR: 7002: org.apache.commons.net.util.ListenerList: Method 'public
java.util.Enumeration getListeners()' has been removed
INFO: 7011: org.apache.commons.net.util.ListenerList: Method 'public
java.util.Iterator iterator()' has been added
INFO: 8000: org.apache.commons.net.whois.WhoisClient: Class
org.apache.commons.net.whois.WhoisClient added
Simon Kitching wrote:
> Sorry, text and xml are the only clirr formats supported as far as I
> know (last time I looked). The text output is fairly readable though not
> pretty I agree.
>
> I'm not sure how well clirr handles java 1.5.
>
> Cheers,
>
> Simon
>
> On Wed, 2006-09-13 at 11:14 +0100, Rory Winston wrote:
>
>> Sure,
>>
>> I can output a clirr report in text or xml, is there any predefined
>> templates to convert it to a more readable format (i.e. HTML)?
>>
>> Rory
>>
>>
>> Stephen Colebourne wrote:
>>
>>> Perhaps you could run a clirr report, and publish the result? That way we can all see what the amount of change in the API is.
>>>
>>> And yes, this cold potentially be a problem with any non backwards-compatible release. As I said before, I'm driving to find out how this release will sit within the wider OSS and user community, and to try and avoid jar-hell.
>>>
>>> Stephen
>>>
>>> ----- Original Message ----
>>> From: Rory Winston <rw...@eircom.net>
>>> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>>> Sent: Wednesday, 13 September, 2006 8:53:27 AM
>>> Subject: Re: [VOTE] Release [net] version 2.0
>>>
>>> Stephen
>>>
>>> I'm afraid I dont really get waht you're asking? Surely this would be a
>>> problem with any project that produces a non-backwards-compatible
>>> release? As for the API, it is 99% backwards compatible - so far, there
>>> are little changes to the public interface.
>>>
>>> Stephen Colebourne wrote:
>>>
>>>
>>>> My question is whether 2.0 is backwards compatible with 1.0. If it
>>>> isn't, then how are we going to handle the situation where two
>>>> different OSS projects refer to two different versions of [net] -
>>>> jar-hell.
>>>>
>>>> Stephen
>>>>
>>>>
>>>> Rory Winston wrote:
>>>>
>>>>
>>>>> Steve
>>>>>
>>>>> Sorry, I should have been more specific
>>>>>
>>>>> 1) Yes, there will be two separate branches of development. At the
>>>>> moment, the trunk is the 1.x branch, whereas there is a separate
>>>>> branch for JDK 5.0 dev. We can keep this the way it is, or swap the
>>>>> trunk and branch at some stage.
>>>>>
>>>>> 2) We need two sites, for sure. I think an easy way would be to do
>>>>> the separate Maven 1 (1.x codebase) and Maven 2.0 (2.x codebase)
>>>>> builds, and just put a link from one site to the other in the Maven
>>>>> menus. Otherwise, if Maven 2 can handle this kind of situation out of
>>>>> the box, we should move the 1.x build over to Maven 2 as well.What do
>>>>> you think?
>>>>>
>>>>> Hope this helps
>>>>> Rory
>>>>>
>>>>> Steve Cohen wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Rory Winston wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> OK, seeing as we have reached some kind of consensus on how to
>>>>>>> handle backards-incompatible JDK releases, I'm restarting the vote
>>>>>>> for a release of Commons::Net 2.0 (the JDK 5.0 branch).
>>>>>>>
>>>>>>> As per usual, just respond with
>>>>>>>
>>>>>>> +1
>>>>>>> +0
>>>>>>> -0
>>>>>>> -1
>>>>>>>
>>>>>>> Thanks
>>>>>>> Rory
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Sorry, Rory, but I think you need to express the consensus that you
>>>>>> think we are voting on. You haven't done that. "release of
>>>>>> Commons::Net 2.0 (the JDK 5.0 branch)" doesn't get to the heart of
>>>>>> all the issues.
>>>>>>
>>>>>> 1: Are there two "official" branches or is 1.4.x relegated to
>>>>>> "backward compatibility mode"? I would insist that there be two
>>>>>> branches until Sun puts 1.4.x into EndOfLife mode.
>>>>>>
>>>>>> 2. Is the site going to be organized to reflect the two branches?
>>>>>>
>>>>>> If those two points are part of your "motion", I'm +1. Otherwise,
>>>>>> I'm -1.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release [net] version 2.0
Posted by Simon Kitching <sk...@apache.org>.
Sorry, text and xml are the only clirr formats supported as far as I
know (last time I looked). The text output is fairly readable though not
pretty I agree.
I'm not sure how well clirr handles java 1.5.
Cheers,
Simon
On Wed, 2006-09-13 at 11:14 +0100, Rory Winston wrote:
> Sure,
>
> I can output a clirr report in text or xml, is there any predefined
> templates to convert it to a more readable format (i.e. HTML)?
>
> Rory
>
>
> Stephen Colebourne wrote:
> > Perhaps you could run a clirr report, and publish the result? That way we can all see what the amount of change in the API is.
> >
> > And yes, this cold potentially be a problem with any non backwards-compatible release. As I said before, I'm driving to find out how this release will sit within the wider OSS and user community, and to try and avoid jar-hell.
> >
> > Stephen
> >
> > ----- Original Message ----
> > From: Rory Winston <rw...@eircom.net>
> > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > Sent: Wednesday, 13 September, 2006 8:53:27 AM
> > Subject: Re: [VOTE] Release [net] version 2.0
> >
> > Stephen
> >
> > I'm afraid I dont really get waht you're asking? Surely this would be a
> > problem with any project that produces a non-backwards-compatible
> > release? As for the API, it is 99% backwards compatible - so far, there
> > are little changes to the public interface.
> >
> > Stephen Colebourne wrote:
> >
> >> My question is whether 2.0 is backwards compatible with 1.0. If it
> >> isn't, then how are we going to handle the situation where two
> >> different OSS projects refer to two different versions of [net] -
> >> jar-hell.
> >>
> >> Stephen
> >>
> >>
> >> Rory Winston wrote:
> >>
> >>> Steve
> >>>
> >>> Sorry, I should have been more specific
> >>>
> >>> 1) Yes, there will be two separate branches of development. At the
> >>> moment, the trunk is the 1.x branch, whereas there is a separate
> >>> branch for JDK 5.0 dev. We can keep this the way it is, or swap the
> >>> trunk and branch at some stage.
> >>>
> >>> 2) We need two sites, for sure. I think an easy way would be to do
> >>> the separate Maven 1 (1.x codebase) and Maven 2.0 (2.x codebase)
> >>> builds, and just put a link from one site to the other in the Maven
> >>> menus. Otherwise, if Maven 2 can handle this kind of situation out of
> >>> the box, we should move the 1.x build over to Maven 2 as well.What do
> >>> you think?
> >>>
> >>> Hope this helps
> >>> Rory
> >>>
> >>> Steve Cohen wrote:
> >>>
> >>>
> >>>> Rory Winston wrote:
> >>>>
> >>>>
> >>>>> OK, seeing as we have reached some kind of consensus on how to
> >>>>> handle backards-incompatible JDK releases, I'm restarting the vote
> >>>>> for a release of Commons::Net 2.0 (the JDK 5.0 branch).
> >>>>>
> >>>>> As per usual, just respond with
> >>>>>
> >>>>> +1
> >>>>> +0
> >>>>> -0
> >>>>> -1
> >>>>>
> >>>>> Thanks
> >>>>> Rory
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> Sorry, Rory, but I think you need to express the consensus that you
> >>>> think we are voting on. You haven't done that. "release of
> >>>> Commons::Net 2.0 (the JDK 5.0 branch)" doesn't get to the heart of
> >>>> all the issues.
> >>>>
> >>>> 1: Are there two "official" branches or is 1.4.x relegated to
> >>>> "backward compatibility mode"? I would insist that there be two
> >>>> branches until Sun puts 1.4.x into EndOfLife mode.
> >>>>
> >>>> 2. Is the site going to be organized to reflect the two branches?
> >>>>
> >>>> If those two points are part of your "motion", I'm +1. Otherwise,
> >>>> I'm -1.
> >>>>
> >>>> Steve
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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
> >>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release [net] version 2.0
Posted by Rory Winston <rw...@eircom.net>.
Sure,
I can output a clirr report in text or xml, is there any predefined
templates to convert it to a more readable format (i.e. HTML)?
Rory
Stephen Colebourne wrote:
> Perhaps you could run a clirr report, and publish the result? That way we can all see what the amount of change in the API is.
>
> And yes, this cold potentially be a problem with any non backwards-compatible release. As I said before, I'm driving to find out how this release will sit within the wider OSS and user community, and to try and avoid jar-hell.
>
> Stephen
>
> ----- Original Message ----
> From: Rory Winston <rw...@eircom.net>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Sent: Wednesday, 13 September, 2006 8:53:27 AM
> Subject: Re: [VOTE] Release [net] version 2.0
>
> Stephen
>
> I'm afraid I dont really get waht you're asking? Surely this would be a
> problem with any project that produces a non-backwards-compatible
> release? As for the API, it is 99% backwards compatible - so far, there
> are little changes to the public interface.
>
> Stephen Colebourne wrote:
>
>> My question is whether 2.0 is backwards compatible with 1.0. If it
>> isn't, then how are we going to handle the situation where two
>> different OSS projects refer to two different versions of [net] -
>> jar-hell.
>>
>> Stephen
>>
>>
>> Rory Winston wrote:
>>
>>> Steve
>>>
>>> Sorry, I should have been more specific
>>>
>>> 1) Yes, there will be two separate branches of development. At the
>>> moment, the trunk is the 1.x branch, whereas there is a separate
>>> branch for JDK 5.0 dev. We can keep this the way it is, or swap the
>>> trunk and branch at some stage.
>>>
>>> 2) We need two sites, for sure. I think an easy way would be to do
>>> the separate Maven 1 (1.x codebase) and Maven 2.0 (2.x codebase)
>>> builds, and just put a link from one site to the other in the Maven
>>> menus. Otherwise, if Maven 2 can handle this kind of situation out of
>>> the box, we should move the 1.x build over to Maven 2 as well.What do
>>> you think?
>>>
>>> Hope this helps
>>> Rory
>>>
>>> Steve Cohen wrote:
>>>
>>>
>>>> Rory Winston wrote:
>>>>
>>>>
>>>>> OK, seeing as we have reached some kind of consensus on how to
>>>>> handle backards-incompatible JDK releases, I'm restarting the vote
>>>>> for a release of Commons::Net 2.0 (the JDK 5.0 branch).
>>>>>
>>>>> As per usual, just respond with
>>>>>
>>>>> +1
>>>>> +0
>>>>> -0
>>>>> -1
>>>>>
>>>>> Thanks
>>>>> Rory
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Sorry, Rory, but I think you need to express the consensus that you
>>>> think we are voting on. You haven't done that. "release of
>>>> Commons::Net 2.0 (the JDK 5.0 branch)" doesn't get to the heart of
>>>> all the issues.
>>>>
>>>> 1: Are there two "official" branches or is 1.4.x relegated to
>>>> "backward compatibility mode"? I would insist that there be two
>>>> branches until Sun puts 1.4.x into EndOfLife mode.
>>>>
>>>> 2. Is the site going to be organized to reflect the two branches?
>>>>
>>>> If those two points are part of your "motion", I'm +1. Otherwise,
>>>> I'm -1.
>>>>
>>>> Steve
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release [net] version 2.0
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Perhaps you could run a clirr report, and publish the result? That way we can all see what the amount of change in the API is.
And yes, this cold potentially be a problem with any non backwards-compatible release. As I said before, I'm driving to find out how this release will sit within the wider OSS and user community, and to try and avoid jar-hell.
Stephen
----- Original Message ----
From: Rory Winston <rw...@eircom.net>
To: Jakarta Commons Developers List <co...@jakarta.apache.org>
Sent: Wednesday, 13 September, 2006 8:53:27 AM
Subject: Re: [VOTE] Release [net] version 2.0
Stephen
I'm afraid I dont really get waht you're asking? Surely this would be a
problem with any project that produces a non-backwards-compatible
release? As for the API, it is 99% backwards compatible - so far, there
are little changes to the public interface.
Stephen Colebourne wrote:
> My question is whether 2.0 is backwards compatible with 1.0. If it
> isn't, then how are we going to handle the situation where two
> different OSS projects refer to two different versions of [net] -
> jar-hell.
>
> Stephen
>
>
> Rory Winston wrote:
>> Steve
>>
>> Sorry, I should have been more specific
>>
>> 1) Yes, there will be two separate branches of development. At the
>> moment, the trunk is the 1.x branch, whereas there is a separate
>> branch for JDK 5.0 dev. We can keep this the way it is, or swap the
>> trunk and branch at some stage.
>>
>> 2) We need two sites, for sure. I think an easy way would be to do
>> the separate Maven 1 (1.x codebase) and Maven 2.0 (2.x codebase)
>> builds, and just put a link from one site to the other in the Maven
>> menus. Otherwise, if Maven 2 can handle this kind of situation out of
>> the box, we should move the 1.x build over to Maven 2 as well.What do
>> you think?
>>
>> Hope this helps
>> Rory
>>
>> Steve Cohen wrote:
>>
>>> Rory Winston wrote:
>>>
>>>> OK, seeing as we have reached some kind of consensus on how to
>>>> handle backards-incompatible JDK releases, I'm restarting the vote
>>>> for a release of Commons::Net 2.0 (the JDK 5.0 branch).
>>>>
>>>> As per usual, just respond with
>>>>
>>>> +1
>>>> +0
>>>> -0
>>>> -1
>>>>
>>>> Thanks
>>>> Rory
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>> Sorry, Rory, but I think you need to express the consensus that you
>>> think we are voting on. You haven't done that. "release of
>>> Commons::Net 2.0 (the JDK 5.0 branch)" doesn't get to the heart of
>>> all the issues.
>>>
>>> 1: Are there two "official" branches or is 1.4.x relegated to
>>> "backward compatibility mode"? I would insist that there be two
>>> branches until Sun puts 1.4.x into EndOfLife mode.
>>>
>>> 2. Is the site going to be organized to reflect the two branches?
>>>
>>> If those two points are part of your "motion", I'm +1. Otherwise,
>>> I'm -1.
>>>
>>> Steve
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release [net] version 2.0
Posted by Rory Winston <rw...@eircom.net>.
Stephen
I'm afraid I dont really get waht you're asking? Surely this would be a
problem with any project that produces a non-backwards-compatible
release? As for the API, it is 99% backwards compatible - so far, there
are little changes to the public interface.
Stephen Colebourne wrote:
> My question is whether 2.0 is backwards compatible with 1.0. If it
> isn't, then how are we going to handle the situation where two
> different OSS projects refer to two different versions of [net] -
> jar-hell.
>
> Stephen
>
>
> Rory Winston wrote:
>> Steve
>>
>> Sorry, I should have been more specific
>>
>> 1) Yes, there will be two separate branches of development. At the
>> moment, the trunk is the 1.x branch, whereas there is a separate
>> branch for JDK 5.0 dev. We can keep this the way it is, or swap the
>> trunk and branch at some stage.
>>
>> 2) We need two sites, for sure. I think an easy way would be to do
>> the separate Maven 1 (1.x codebase) and Maven 2.0 (2.x codebase)
>> builds, and just put a link from one site to the other in the Maven
>> menus. Otherwise, if Maven 2 can handle this kind of situation out of
>> the box, we should move the 1.x build over to Maven 2 as well.What do
>> you think?
>>
>> Hope this helps
>> Rory
>>
>> Steve Cohen wrote:
>>
>>> Rory Winston wrote:
>>>
>>>> OK, seeing as we have reached some kind of consensus on how to
>>>> handle backards-incompatible JDK releases, I'm restarting the vote
>>>> for a release of Commons::Net 2.0 (the JDK 5.0 branch).
>>>>
>>>> As per usual, just respond with
>>>>
>>>> +1
>>>> +0
>>>> -0
>>>> -1
>>>>
>>>> Thanks
>>>> Rory
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>> Sorry, Rory, but I think you need to express the consensus that you
>>> think we are voting on. You haven't done that. "release of
>>> Commons::Net 2.0 (the JDK 5.0 branch)" doesn't get to the heart of
>>> all the issues.
>>>
>>> 1: Are there two "official" branches or is 1.4.x relegated to
>>> "backward compatibility mode"? I would insist that there be two
>>> branches until Sun puts 1.4.x into EndOfLife mode.
>>>
>>> 2. Is the site going to be organized to reflect the two branches?
>>>
>>> If those two points are part of your "motion", I'm +1. Otherwise,
>>> I'm -1.
>>>
>>> Steve
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release [net] version 2.0
Posted by Stephen Colebourne <sc...@btopenworld.com>.
My question is whether 2.0 is backwards compatible with 1.0. If it
isn't, then how are we going to handle the situation where two different
OSS projects refer to two different versions of [net] - jar-hell.
Stephen
Rory Winston wrote:
> Steve
>
> Sorry, I should have been more specific
>
> 1) Yes, there will be two separate branches of development. At the
> moment, the trunk is the 1.x branch, whereas there is a separate branch
> for JDK 5.0 dev. We can keep this the way it is, or swap the trunk and
> branch at some stage.
>
> 2) We need two sites, for sure. I think an easy way would be to do the
> separate Maven 1 (1.x codebase) and Maven 2.0 (2.x codebase) builds, and
> just put a link from one site to the other in the Maven menus.
> Otherwise, if Maven 2 can handle this kind of situation out of the box,
> we should move the 1.x build over to Maven 2 as well.What do you think?
>
> Hope this helps
> Rory
>
> Steve Cohen wrote:
>
>> Rory Winston wrote:
>>
>>> OK, seeing as we have reached some kind of consensus on how to handle
>>> backards-incompatible JDK releases, I'm restarting the vote for a
>>> release of Commons::Net 2.0 (the JDK 5.0 branch).
>>>
>>> As per usual, just respond with
>>>
>>> +1
>>> +0
>>> -0
>>> -1
>>>
>>> Thanks
>>> Rory
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>> Sorry, Rory, but I think you need to express the consensus that you
>> think we are voting on. You haven't done that. "release of
>> Commons::Net 2.0 (the JDK 5.0 branch)" doesn't get to the heart of all
>> the issues.
>>
>> 1: Are there two "official" branches or is 1.4.x relegated to
>> "backward compatibility mode"? I would insist that there be two
>> branches until Sun puts 1.4.x into EndOfLife mode.
>>
>> 2. Is the site going to be organized to reflect the two branches?
>>
>> If those two points are part of your "motion", I'm +1. Otherwise, I'm
>> -1.
>>
>> Steve
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release [net] version 2.0
Posted by Rory Winston <rw...@eircom.net>.
Niklas
This may be a possibility for the 1.x branch as well. Note that FTPS
support for older JDKs will require an extra JSSE dependency.
Rory
Niklas Gustavsson wrote:
> Rory Winston wrote:
>> 1) Yes, there will be two separate branches of development. At the
>> moment, the trunk is the 1.x branch, whereas there is a separate
>> branch for JDK 5.0 dev. We can keep this the way it is, or swap the
>> trunk and branch at some stage.
>
> Will you be backporting new features from the 2.x to the 1.x branch?
> I'm thinking of for example the FTPS support.
>
> /niklas
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release [net] version 2.0
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Rory Winston wrote:
> 1) Yes, there will be two separate branches of development. At the
> moment, the trunk is the 1.x branch, whereas there is a separate branch
> for JDK 5.0 dev. We can keep this the way it is, or swap the trunk and
> branch at some stage.
Will you be backporting new features from the 2.x to the 1.x branch? I'm
thinking of for example the FTPS support.
/niklas
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release [net] version 2.0
Posted by Rory Winston <rw...@eircom.net>.
Steve
Sorry, I should have been more specific
1) Yes, there will be two separate branches of development. At the
moment, the trunk is the 1.x branch, whereas there is a separate branch
for JDK 5.0 dev. We can keep this the way it is, or swap the trunk and
branch at some stage.
2) We need two sites, for sure. I think an easy way would be to do the
separate Maven 1 (1.x codebase) and Maven 2.0 (2.x codebase) builds, and
just put a link from one site to the other in the Maven menus.
Otherwise, if Maven 2 can handle this kind of situation out of the box,
we should move the 1.x build over to Maven 2 as well.What do you think?
Hope this helps
Rory
Steve Cohen wrote:
> Rory Winston wrote:
>> OK, seeing as we have reached some kind of consensus on how to handle
>> backards-incompatible JDK releases, I'm restarting the vote for a
>> release of Commons::Net 2.0 (the JDK 5.0 branch).
>>
>> As per usual, just respond with
>>
>> +1
>> +0
>> -0
>> -1
>>
>> Thanks
>> Rory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
> Sorry, Rory, but I think you need to express the consensus that you
> think we are voting on. You haven't done that. "release of
> Commons::Net 2.0 (the JDK 5.0 branch)" doesn't get to the heart of all
> the issues.
>
> 1: Are there two "official" branches or is 1.4.x relegated to
> "backward compatibility mode"? I would insist that there be two
> branches until Sun puts 1.4.x into EndOfLife mode.
>
> 2. Is the site going to be organized to reflect the two branches?
>
> If those two points are part of your "motion", I'm +1. Otherwise, I'm
> -1.
>
> Steve
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release [net] version 2.0
Posted by Steve Cohen <sc...@javactivity.org>.
Rory Winston wrote:
> OK, seeing as we have reached some kind of consensus on how to handle
> backards-incompatible JDK releases, I'm restarting the vote for a
> release of Commons::Net 2.0 (the JDK 5.0 branch).
>
> As per usual, just respond with
>
> +1
> +0
> -0
> -1
>
> Thanks
> Rory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
Sorry, Rory, but I think you need to express the consensus that you think we are
voting on. You haven't done that. "release of Commons::Net 2.0 (the JDK 5.0
branch)" doesn't get to the heart of all the issues.
1: Are there two "official" branches or is 1.4.x relegated to "backward
compatibility mode"? I would insist that there be two branches until Sun puts
1.4.x into EndOfLife mode.
2. Is the site going to be organized to reflect the two branches?
If those two points are part of your "motion", I'm +1. Otherwise, I'm -1.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[VOTE] Release [net] version 2.0
Posted by Rory Winston <rw...@eircom.net>.
OK, seeing as we have reached some kind of consensus on how to handle
backards-incompatible JDK releases, I'm restarting the vote for a
release of Commons::Net 2.0 (the JDK 5.0 branch).
As per usual, just respond with
+1
+0
-0
-1
Thanks
Rory
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Brett Porter <br...@apache.org>.
oops! Thanks for the clarification - I'd never had any problems
myself, but I thought I'd gotten that indication from the release
notes/web site. Long while ago now, obviously my memory isn't so good.
- Brett
On 11/09/2006, at 7:55 AM, Stephen Colebourne wrote:
> Brett Porter wrote:
>> Didn't collections go through this (backwards-incompatible API
>> change, not a JDK5-ification) Îin the past for 3.0? Any
>> experiences that can be learned from there?
>
> [collections] 3.0 has been FUDed with the backwards incompatible
> tag ever since it was released, but it was never exactly true. The
> release rewrote many classes, and tidied many APIs, but did so by
> moving them into new packages. The original classes were
> deprecated, so no problems...
>
> ...except that one backwards incompatible change did sneak in -
> where the return type of a constant was changed. The clirr tool
> would have caught it, but didn't exist then.
>
> Stephen
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Brett Porter wrote:
> Didn't collections go through this
> (backwards-incompatible API change, not a JDK5-ification) Îin the past
> for 3.0? Any experiences that can be learned from there?
[collections] 3.0 has been FUDed with the backwards incompatible tag
ever since it was released, but it was never exactly true. The release
rewrote many classes, and tidied many APIs, but did so by moving them
into new packages. The original classes were deprecated, so no problems...
...except that one backwards incompatible change did sneak in - where
the return type of a constant was changed. The clirr tool would have
caught it, but didn't exist then.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Brett Porter <br...@apache.org>.
You'd integrate it into your builds. However, this doesn't help with
missing APIs (though I believe retrotranslator does take care of some
of these). It's a pretty good solution for providing JDK 5 binaries
for JDK 1.4.
However, I don't think this addresses the issue being faced - and it
isn't entirely a JDK 5 related one, but something that is faced
whenever a component might want an extreme makeover.
IMO, this is the best pattern to follow:
- keep the maintenance branches going for the previous release, and
bump trunk to the next major version
- if new functionality can be isolated to a new package or a separate
module, do that (eg, some libraries like xwork have an xwork-tiger
module for jdk5 related code)
- if the update can remain api compatible, then there is no need to
change package names (eg, the JDK added generics to a lot of the
runtime without making incompatible changes to the public interfaces)
- if the update must change the api, consider changing the package
name (but only do so if there is a need to use both versions of the
jar in a single classloader, for example lucene was able to safely
overhaul their api for 2.0 because it would be unlikely both would be
in the same classloader)
Obviously, the final one is a last resort and should be avoided -
especially since that case would be quite prevalent for commons. If
it really really really was needed for some reason, I'd call it
o.a.c.net2 (or hopefully something better) rather than net5,
reflecting the API not the JDK it is designed for because that'll
quickly be outdated as JDK 6 comes out.
I think these are all general principles to apply to API evolution,
not just for JDK 5 related changes. Didn't collections go through
this (backwards-incompatible API change, not a JDK5-ification) Îin
the past for 3.0? Any experiences that can be learned from there?
HTH,
Brett
On 11/09/2006, at 7:16 AM, Henri Yandell wrote:
> How does that work exactly? Can we happily write 1.5 stuff and then
> let the user take the 1.5 jar and retroweave it before using it, or do
> we have to integrate retroweaver into our builds (though not our
> sources I hope?)?
>
> Hen
>
> On 9/10/06, Jochen Wiedmann <jo...@gmail.com> wrote:
>> May I point out, that tools like retroweaver or retrotranslator
>> can be
>> used to write code with most 1.5 features while still compiling for
>> 1.4? I don't know whether this applies to the commons-net project,
>> but
>> for most projects I know, this should still be fine.
>>
>>
>> Jochen
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Henri Yandell <fl...@gmail.com>.
How does that work exactly? Can we happily write 1.5 stuff and then
let the user take the 1.5 jar and retroweave it before using it, or do
we have to integrate retroweaver into our builds (though not our
sources I hope?)?
Hen
On 9/10/06, Jochen Wiedmann <jo...@gmail.com> wrote:
> May I point out, that tools like retroweaver or retrotranslator can be
> used to write code with most 1.5 features while still compiling for
> 1.4? I don't know whether this applies to the commons-net project, but
> for most projects I know, this should still be fine.
>
>
> Jochen
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Jochen Wiedmann <jo...@gmail.com>.
May I point out, that tools like retroweaver or retrotranslator can be
used to write code with most 1.5 features while still compiling for
1.4? I don't know whether this applies to the commons-net project, but
for most projects I know, this should still be fine.
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Steve Cohen <sc...@javactivity.org>.
I think we are in agreement. I would be available to do some of the backporting
work if we go down this path.
Does anyone have anything to say about making the site a dual site (something
like Tomcat does)? How difficult is that? Does Maven 2 aid in such a process,
can it build a site from two different SVN branches at once? Or is it really
just two sites that link to one another?
Rory Winston wrote:
> I agree with the major points that Steve has made below. I would think
> that a logical way to go (at least for [net]} would be :
>
> * Version 2.0 (JDK 5.0+) becomes the main development branch, and the
> focal point for new features;
> * Version 1.x continues to be supported, in that fixes and new features
> are backported where possible, and code submitted by the community
> targeted at the 1.x branch can still be applied.
>
> I think this is a pretty reasonable way of moving forward, encouraging
> new development on a codebase free of the shackles of legacy
> limitations, whilst still being able to service users with more
> conservative requirements.
>
>
> Rory
>
>
>
> Steve Cohen wrote:
>> Continuing the discussion:
>>
>> 1. Regex support is in 1.4. It's only because we were trying to stay
>> 1.2/1.3 compatible that we couldn't use it. That's a small point. I
>> doubt we want to have (say) a 1.4.2 branch that requires 1.4 after
>> having supported 1.2/1.3 for all these years, if our soon-to-be target
>> is 1.5. I do agree that the oro dependency has been a very annoying
>> pebble in the shoe.
>>
>> 2. I'm not comfortable with the .net5 package name. I see a cvs
>> nightmare down that road. I guess SVN can handle that but it's still
>> ugly. It makes upgrade for clients of net a maintenance nightmare.
>>
>> 3. > JDK 5.0 has been officially released for around
>> > two years. In my opinion, there shouldn't even be a debate. It
>> should be
>> > taken advantage of, and supported, although not at the expense of
>> > existing users on older versions.
>>
>> No, there unfortunately does need to be this debate. Sun has not
>> end-of-lifed 1.4.2. That is important. They continue to release new
>> subreleases of 1.4.2. Why? Important clients are still not ready to
>> use 5.0. My employer, a very large corporation, now mandates the use
>> of 5.0 but is forced immediately to relent on this mandate for some of
>> its most important projects because it also still uses a lot of
>> Websphere which still does not support 5.0 (and won't until WebSphere
>> 7 is released and even then it will be some time before the server
>> teams are ready to make that switch - they dragged their feet on
>> Websphere 6 until recently). So Sun has to support 1.4 (and continues
>> to have to make new subreleases of 1.4.2 for reasons such as the new
>> daylight savings time start/end dates). The world marches on even
>> when corporate java clients do not.
>>
>> Backward compatibility's a bitch, but if Sun has to worry about this,
>> I think we do too. I don't think jakarta-commons has ever
>> "downgraded" a version of java that Sun considers live.
>>
>> And yet, as Rory says, there are some compelling reasons to do so. I'd
>> love to use JDK 5.0. It hasn't been a possibility for me yet. Even
>> outside of work, for a long time Eclipse did not support 5.0 although
>> I don't think it is anymore.
>>
>> So what is the solution? What does it mean to say "not at the expense
>> of existing users on older versions?" I think we'd need to modify the
>> site to have full support for two release branches, with some easy
>> switch between them. There should be navigation menu items on the 2.0
>> site that point back to the 1.4.x site and vice versa as is the case
>> with Tomcat and other projects. We can't just say all new development
>> will be on 2.0, we'll continue to make 1.4.1 available for those who
>> can't make the move. We may want to say that, but I don't think our
>> user base will let us. Until Sun EOL's 1.4.x, I think our policy must
>> be that every change that can be supported on pre-2.0 will be
>> supported there.
>>
>> I also wonder if this should be a jakarta-commons-wide policy and not
>> just something that net does.
>>
>>
>> Rory Winston wrote:
>>> Hey guys
>>>
>>> An interesting discussion here. I'll try to address some of the
>>> points raised and give my take on the issue.
>>>
>>> * As far as [net] specifically is concerned, there are very few
>>> things that 1.5 makes possible that you really can't do on 1.3 (One
>>> of these is asynchronous I/O and a select()-based thread notification
>>> model). However, 1.5 does make a *ton* of things much cleaner. For
>>> instance, regex support is now on a par with [oro], so we lose our
>>> only external dependency, making [net] a self-contained single jar
>>> download. We can also support secure FTP without having to install a
>>> separate JSSE jar, as SSL/TLS support is now integral in JCE. Apart
>>> from that, there are many, many, smaller enhancements that we can
>>> make. See
>>>
>>> http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html#2.0
>>>
>>>
>>> for a few.
>>>
>>> * As far as I am concerned, the ideal scenario for a project like
>>> [net] is that 1.5+ support continues on a different version line. It
>>> may be the trunk, it may be a branch. So for [net], the 1.x line is
>>> for JDK 1.4.x and below, and the 2.0 line is 1.5+. It doesn't in any
>>> way mean that support is suddenly dropped for pre-Tiger releases. But
>>> sooner or later, 2.0 is the main development version, and that's
>>> where the effort should go.
>>>
>>> * I don't like the concept of a ".net5" package name. Does this mean
>>> that we need a ".net6" package space when JDK 6 is released? It
>>> doesn't feel elegant, and it loses one of the big advantages that the
>>> current system has : a user can upgrade their JDK from 1.3 to 5.0
>>> overnight, download a new [net] 2.0 jar, and their FTPClient-based
>>> code should *just work* (with a 90% probability ;)).
>>>
>>> * I agree with Henri's comment below about Commons being a
>>> "maintenance" vs. "development" space. JDK 5.0 has been officially
>>> released for around two years. In my opinion, there shouldn't even be
>>> a debate. It should be taken advantage of, and supported, although
>>> not at the expense of existing users on older versions.
>>>
>>> Cheers
>>> Rory
>>>
>>>
>>>
>>> Henri Yandell wrote:
>>>> On 9/9/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
>>>>> Steve Cohen wrote:
>>>>> > I am not ready to vote yet on this until there is a discussion about
>>>>> > what this release means. Will commons-net-2.0 become the "official"
>>>>> > release, with previous versions relegated to "backward
>>>>> compatibility"
>>>>> > support? If so, this may be premature as Sun is still supporting
>>>>> > JDK-1.4.2-x.
>>>>> >
>>>>> > But I don't think we should stand in the way of progress either.
>>>>> Rory,
>>>>> > can you comment on what are the specific new features that demand
>>>>> JDK
>>>>> > 5.0 support?
>>>>> >
>>>>> > How have other jakarta-commons projects handled this? Are there any
>>>>> > official versions that require 1.5? Are there projects that have
>>>>> two
>>>>> > "official" releases?
>>>>>
>>>>> I see this as a positive step (a JDK 1.5 only release).
>>>>> I also see this as the right jump (from JDK 1.2/1.3 to 1.5).
>>>>
>>>> I'm a strong +1 for JDK 1.5 dependence.
>>>>
>>>> The way I see it is that while we're supporting 1.2->1.4, new
>>>> development happens on 1.5 so the only time we need to worry about
>>>> older JVMs is for critical bugfixes on maintenance systems - not for
>>>> new development.
>>>>
>>>> Trying to focus on old JVMs makes us a maintenance project, not a
>>>> development project and that's damaging for the project health.
>>>>
>>>> Lang 2.2 is in a limbo state because I can't get 1.2 for my Mac, I
>>>> need to dig into Ubuntu to try and get it to work there and I can't
>>>> even figure out how to get it to work on Windows at the moment (JDK
>>>> 1.6 appears to be taking over the JAVA_HOME and PATH, but it's not
>>>> defined in the user's environment variables).
>>>>
>>>> Another reason is that Lang has tests that fail to pass on 1.2 and
>>>> 1.3; possibly due to bugs in the JVM (time crap). Even once I can make
>>>> a 1.2/1.3 build, I'm not sure if I should.
>>>>
>>>> Plus other reasons, such as being without a happy laptop at home until
>>>> tonight :)
>>>>
>>>>> However, I believe that commons holds an almost unique place in Java
>>>>> development being the lowest layer in many many open source
>>>>> projects. As
>>>>> such making an incompatible major version change is a *very* big deal.
>>>>>
>>>>> [PROPOSAL]
>>>>> As such, I would like to propose that projects creating a JDK1.5 only
>>>>> release should use a new package name. Thus, in this case, the release
>>>>> would use the package org.apache.commons.net5.*.
>>>>
>>>> -1 for a slew of reasons.
>>>>
>>>> * Lots of source code would have to be touched just to upgrade; big
>>>> pain in the arse for something that is quite likely to not involve any
>>>> other change to a user's source.
>>>>
>>>> * Building v49 class files is going to explode on a v48 JVM, so people
>>>> are going to be stopped pretty quickly from using the net5 on their
>>>> old JVM. We don't need to protect them via packages.
>>>>
>>>> * Do we do net3 and net4 if we move from 1.2 to 1.3/1.4? Do we do net6?
>>>>
>>>>> With this change, a user can have both the old and the new commons-net
>>>>> jars in their classpath without any conflicts.
>>>>
>>>> Only a JDK 1.5 user (1.6 too I guess). Presuming we make 1.5 targetted
>>>> builds and not 1.2->1.4. And then it's nothing to do with 1.4/1.5 and
>>>> just the classic problem of package clash within dependencies.
>>>>
>>>>> Note that these users may be different OSS projects, which may
>>>>> upgrade at different times.
>>>>>
>>>>> Users wishing to migrate from one version to another can simply do a
>>>>> global search and replace on the package name.
>>>>>
>>>>> We must not underestimate the significance of the low-level
>>>>> position of
>>>>> commons in the Java OSS, and proprietry, communities. A clear and
>>>>> planned migration strategy for all our modules is needed.
>>>>
>>>> I accept that by its nature Commons is going to cause problems every
>>>> time they release. We're going to be a frequent location for classpath
>>>> clash problems. It's not JVM relevant though, it happens every time we
>>>> release anything so the version you would need in the package name is
>>>> the Commons major version, not the jdk version.
>>>>
>>>> I think we should declare that new development will be on 1.5 -
>>>> building 1.5 only jars. Anyone trying to use them on 1.4 and before is
>>>> going to get a nice error and we can start exploring new JDK features
>>>> like regular expressions *sarc :) *. Then we can stick with it until
>>>> 1.8 is in beta or something.
>>>>
>>>> Hen
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Rory Winston <rw...@eircom.net>.
I agree with the major points that Steve has made below. I would think
that a logical way to go (at least for [net]} would be :
* Version 2.0 (JDK 5.0+) becomes the main development branch, and the
focal point for new features;
* Version 1.x continues to be supported, in that fixes and new features
are backported where possible, and code submitted by the community
targeted at the 1.x branch can still be applied.
I think this is a pretty reasonable way of moving forward, encouraging
new development on a codebase free of the shackles of legacy
limitations, whilst still being able to service users with more
conservative requirements.
Rory
Steve Cohen wrote:
> Continuing the discussion:
>
> 1. Regex support is in 1.4. It's only because we were trying to stay
> 1.2/1.3 compatible that we couldn't use it. That's a small point. I
> doubt we want to have (say) a 1.4.2 branch that requires 1.4 after
> having supported 1.2/1.3 for all these years, if our soon-to-be target
> is 1.5. I do agree that the oro dependency has been a very annoying
> pebble in the shoe.
>
> 2. I'm not comfortable with the .net5 package name. I see a cvs
> nightmare down that road. I guess SVN can handle that but it's still
> ugly. It makes upgrade for clients of net a maintenance nightmare.
>
> 3. > JDK 5.0 has been officially released for around
> > two years. In my opinion, there shouldn't even be a debate. It
> should be
> > taken advantage of, and supported, although not at the expense of
> > existing users on older versions.
>
> No, there unfortunately does need to be this debate. Sun has not
> end-of-lifed 1.4.2. That is important. They continue to release new
> subreleases of 1.4.2. Why? Important clients are still not ready to
> use 5.0. My employer, a very large corporation, now mandates the use
> of 5.0 but is forced immediately to relent on this mandate for some of
> its most important projects because it also still uses a lot of
> Websphere which still does not support 5.0 (and won't until WebSphere
> 7 is released and even then it will be some time before the server
> teams are ready to make that switch - they dragged their feet on
> Websphere 6 until recently). So Sun has to support 1.4 (and continues
> to have to make new subreleases of 1.4.2 for reasons such as the new
> daylight savings time start/end dates). The world marches on even
> when corporate java clients do not.
>
> Backward compatibility's a bitch, but if Sun has to worry about this,
> I think we do too. I don't think jakarta-commons has ever
> "downgraded" a version of java that Sun considers live.
>
> And yet, as Rory says, there are some compelling reasons to do so. I'd
> love to use JDK 5.0. It hasn't been a possibility for me yet. Even
> outside of work, for a long time Eclipse did not support 5.0 although
> I don't think it is anymore.
>
> So what is the solution? What does it mean to say "not at the expense
> of existing users on older versions?" I think we'd need to modify the
> site to have full support for two release branches, with some easy
> switch between them. There should be navigation menu items on the 2.0
> site that point back to the 1.4.x site and vice versa as is the case
> with Tomcat and other projects. We can't just say all new development
> will be on 2.0, we'll continue to make 1.4.1 available for those who
> can't make the move. We may want to say that, but I don't think our
> user base will let us. Until Sun EOL's 1.4.x, I think our policy must
> be that every change that can be supported on pre-2.0 will be
> supported there.
>
> I also wonder if this should be a jakarta-commons-wide policy and not
> just something that net does.
>
>
> Rory Winston wrote:
>> Hey guys
>>
>> An interesting discussion here. I'll try to address some of the
>> points raised and give my take on the issue.
>>
>> * As far as [net] specifically is concerned, there are very few
>> things that 1.5 makes possible that you really can't do on 1.3 (One
>> of these is asynchronous I/O and a select()-based thread notification
>> model). However, 1.5 does make a *ton* of things much cleaner. For
>> instance, regex support is now on a par with [oro], so we lose our
>> only external dependency, making [net] a self-contained single jar
>> download. We can also support secure FTP without having to install a
>> separate JSSE jar, as SSL/TLS support is now integral in JCE. Apart
>> from that, there are many, many, smaller enhancements that we can
>> make. See
>>
>> http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html#2.0
>>
>>
>> for a few.
>>
>> * As far as I am concerned, the ideal scenario for a project like
>> [net] is that 1.5+ support continues on a different version line. It
>> may be the trunk, it may be a branch. So for [net], the 1.x line is
>> for JDK 1.4.x and below, and the 2.0 line is 1.5+. It doesn't in any
>> way mean that support is suddenly dropped for pre-Tiger releases. But
>> sooner or later, 2.0 is the main development version, and that's
>> where the effort should go.
>>
>> * I don't like the concept of a ".net5" package name. Does this mean
>> that we need a ".net6" package space when JDK 6 is released? It
>> doesn't feel elegant, and it loses one of the big advantages that the
>> current system has : a user can upgrade their JDK from 1.3 to 5.0
>> overnight, download a new [net] 2.0 jar, and their FTPClient-based
>> code should *just work* (with a 90% probability ;)).
>>
>> * I agree with Henri's comment below about Commons being a
>> "maintenance" vs. "development" space. JDK 5.0 has been officially
>> released for around two years. In my opinion, there shouldn't even be
>> a debate. It should be taken advantage of, and supported, although
>> not at the expense of existing users on older versions.
>>
>> Cheers
>> Rory
>>
>>
>>
>> Henri Yandell wrote:
>>> On 9/9/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
>>>> Steve Cohen wrote:
>>>> > I am not ready to vote yet on this until there is a discussion about
>>>> > what this release means. Will commons-net-2.0 become the "official"
>>>> > release, with previous versions relegated to "backward
>>>> compatibility"
>>>> > support? If so, this may be premature as Sun is still supporting
>>>> > JDK-1.4.2-x.
>>>> >
>>>> > But I don't think we should stand in the way of progress either.
>>>> Rory,
>>>> > can you comment on what are the specific new features that demand
>>>> JDK
>>>> > 5.0 support?
>>>> >
>>>> > How have other jakarta-commons projects handled this? Are there any
>>>> > official versions that require 1.5? Are there projects that have
>>>> two
>>>> > "official" releases?
>>>>
>>>> I see this as a positive step (a JDK 1.5 only release).
>>>> I also see this as the right jump (from JDK 1.2/1.3 to 1.5).
>>>
>>> I'm a strong +1 for JDK 1.5 dependence.
>>>
>>> The way I see it is that while we're supporting 1.2->1.4, new
>>> development happens on 1.5 so the only time we need to worry about
>>> older JVMs is for critical bugfixes on maintenance systems - not for
>>> new development.
>>>
>>> Trying to focus on old JVMs makes us a maintenance project, not a
>>> development project and that's damaging for the project health.
>>>
>>> Lang 2.2 is in a limbo state because I can't get 1.2 for my Mac, I
>>> need to dig into Ubuntu to try and get it to work there and I can't
>>> even figure out how to get it to work on Windows at the moment (JDK
>>> 1.6 appears to be taking over the JAVA_HOME and PATH, but it's not
>>> defined in the user's environment variables).
>>>
>>> Another reason is that Lang has tests that fail to pass on 1.2 and
>>> 1.3; possibly due to bugs in the JVM (time crap). Even once I can make
>>> a 1.2/1.3 build, I'm not sure if I should.
>>>
>>> Plus other reasons, such as being without a happy laptop at home until
>>> tonight :)
>>>
>>>> However, I believe that commons holds an almost unique place in Java
>>>> development being the lowest layer in many many open source
>>>> projects. As
>>>> such making an incompatible major version change is a *very* big deal.
>>>>
>>>> [PROPOSAL]
>>>> As such, I would like to propose that projects creating a JDK1.5 only
>>>> release should use a new package name. Thus, in this case, the release
>>>> would use the package org.apache.commons.net5.*.
>>>
>>> -1 for a slew of reasons.
>>>
>>> * Lots of source code would have to be touched just to upgrade; big
>>> pain in the arse for something that is quite likely to not involve any
>>> other change to a user's source.
>>>
>>> * Building v49 class files is going to explode on a v48 JVM, so people
>>> are going to be stopped pretty quickly from using the net5 on their
>>> old JVM. We don't need to protect them via packages.
>>>
>>> * Do we do net3 and net4 if we move from 1.2 to 1.3/1.4? Do we do net6?
>>>
>>>> With this change, a user can have both the old and the new commons-net
>>>> jars in their classpath without any conflicts.
>>>
>>> Only a JDK 1.5 user (1.6 too I guess). Presuming we make 1.5 targetted
>>> builds and not 1.2->1.4. And then it's nothing to do with 1.4/1.5 and
>>> just the classic problem of package clash within dependencies.
>>>
>>>> Note that these users may be different OSS projects, which may
>>>> upgrade at different times.
>>>>
>>>> Users wishing to migrate from one version to another can simply do a
>>>> global search and replace on the package name.
>>>>
>>>> We must not underestimate the significance of the low-level
>>>> position of
>>>> commons in the Java OSS, and proprietry, communities. A clear and
>>>> planned migration strategy for all our modules is needed.
>>>
>>> I accept that by its nature Commons is going to cause problems every
>>> time they release. We're going to be a frequent location for classpath
>>> clash problems. It's not JVM relevant though, it happens every time we
>>> release anything so the version you would need in the package name is
>>> the Commons major version, not the jdk version.
>>>
>>> I think we should declare that new development will be on 1.5 -
>>> building 1.5 only jars. Anyone trying to use them on 1.4 and before is
>>> going to get a nice error and we can start exploring new JDK features
>>> like regular expressions *sarc :) *. Then we can stick with it until
>>> 1.8 is in beta or something.
>>>
>>> Hen
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Steve Cohen <sc...@javactivity.org>.
Continuing the discussion:
1. Regex support is in 1.4. It's only because we were trying to stay 1.2/1.3
compatible that we couldn't use it. That's a small point. I doubt we want to
have (say) a 1.4.2 branch that requires 1.4 after having supported 1.2/1.3 for
all these years, if our soon-to-be target is 1.5. I do agree that the oro
dependency has been a very annoying pebble in the shoe.
2. I'm not comfortable with the .net5 package name. I see a cvs nightmare down
that road. I guess SVN can handle that but it's still ugly. It makes upgrade
for clients of net a maintenance nightmare.
3. > JDK 5.0 has been officially released for around
> two years. In my opinion, there shouldn't even be a debate. It should be
> taken advantage of, and supported, although not at the expense of
> existing users on older versions.
No, there unfortunately does need to be this debate. Sun has not end-of-lifed
1.4.2. That is important. They continue to release new subreleases of 1.4.2.
Why? Important clients are still not ready to use 5.0. My employer, a very
large corporation, now mandates the use of 5.0 but is forced immediately to
relent on this mandate for some of its most important projects because it also
still uses a lot of Websphere which still does not support 5.0 (and won't until
WebSphere 7 is released and even then it will be some time before the server
teams are ready to make that switch - they dragged their feet on Websphere 6
until recently). So Sun has to support 1.4 (and continues to have to make new
subreleases of 1.4.2 for reasons such as the new daylight savings time start/end
dates). The world marches on even when corporate java clients do not.
Backward compatibility's a bitch, but if Sun has to worry about this, I think we
do too. I don't think jakarta-commons has ever "downgraded" a version of java
that Sun considers live.
And yet, as Rory says, there are some compelling reasons to do so. I'd love to
use JDK 5.0. It hasn't been a possibility for me yet. Even outside of work,
for a long time Eclipse did not support 5.0 although I don't think it is anymore.
So what is the solution? What does it mean to say "not at the expense of
existing users on older versions?" I think we'd need to modify the site to have
full support for two release branches, with some easy switch between them.
There should be navigation menu items on the 2.0 site that point back to the
1.4.x site and vice versa as is the case with Tomcat and other projects. We
can't just say all new development will be on 2.0, we'll continue to make 1.4.1
available for those who can't make the move. We may want to say that, but I
don't think our user base will let us. Until Sun EOL's 1.4.x, I think our
policy must be that every change that can be supported on pre-2.0 will be
supported there.
I also wonder if this should be a jakarta-commons-wide policy and not just
something that net does.
Rory Winston wrote:
> Hey guys
>
> An interesting discussion here. I'll try to address some of the points
> raised and give my take on the issue.
>
> * As far as [net] specifically is concerned, there are very few things
> that 1.5 makes possible that you really can't do on 1.3 (One of these is
> asynchronous I/O and a select()-based thread notification model).
> However, 1.5 does make a *ton* of things much cleaner. For instance,
> regex support is now on a par with [oro], so we lose our only external
> dependency, making [net] a self-contained single jar download. We can
> also support secure FTP without having to install a separate JSSE jar,
> as SSL/TLS support is now integral in JCE. Apart from that, there are
> many, many, smaller enhancements that we can make. See
>
> http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html#2.0
>
>
> for a few.
>
> * As far as I am concerned, the ideal scenario for a project like [net]
> is that 1.5+ support continues on a different version line. It may be
> the trunk, it may be a branch. So for [net], the 1.x line is for JDK
> 1.4.x and below, and the 2.0 line is 1.5+. It doesn't in any way mean
> that support is suddenly dropped for pre-Tiger releases. But sooner or
> later, 2.0 is the main development version, and that's where the effort
> should go.
>
> * I don't like the concept of a ".net5" package name. Does this mean
> that we need a ".net6" package space when JDK 6 is released? It doesn't
> feel elegant, and it loses one of the big advantages that the current
> system has : a user can upgrade their JDK from 1.3 to 5.0 overnight,
> download a new [net] 2.0 jar, and their FTPClient-based code should
> *just work* (with a 90% probability ;)).
>
> * I agree with Henri's comment below about Commons being a "maintenance"
> vs. "development" space. JDK 5.0 has been officially released for around
> two years. In my opinion, there shouldn't even be a debate. It should be
> taken advantage of, and supported, although not at the expense of
> existing users on older versions.
>
> Cheers
> Rory
>
>
>
> Henri Yandell wrote:
>> On 9/9/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
>>> Steve Cohen wrote:
>>> > I am not ready to vote yet on this until there is a discussion about
>>> > what this release means. Will commons-net-2.0 become the "official"
>>> > release, with previous versions relegated to "backward compatibility"
>>> > support? If so, this may be premature as Sun is still supporting
>>> > JDK-1.4.2-x.
>>> >
>>> > But I don't think we should stand in the way of progress either.
>>> Rory,
>>> > can you comment on what are the specific new features that demand JDK
>>> > 5.0 support?
>>> >
>>> > How have other jakarta-commons projects handled this? Are there any
>>> > official versions that require 1.5? Are there projects that have two
>>> > "official" releases?
>>>
>>> I see this as a positive step (a JDK 1.5 only release).
>>> I also see this as the right jump (from JDK 1.2/1.3 to 1.5).
>>
>> I'm a strong +1 for JDK 1.5 dependence.
>>
>> The way I see it is that while we're supporting 1.2->1.4, new
>> development happens on 1.5 so the only time we need to worry about
>> older JVMs is for critical bugfixes on maintenance systems - not for
>> new development.
>>
>> Trying to focus on old JVMs makes us a maintenance project, not a
>> development project and that's damaging for the project health.
>>
>> Lang 2.2 is in a limbo state because I can't get 1.2 for my Mac, I
>> need to dig into Ubuntu to try and get it to work there and I can't
>> even figure out how to get it to work on Windows at the moment (JDK
>> 1.6 appears to be taking over the JAVA_HOME and PATH, but it's not
>> defined in the user's environment variables).
>>
>> Another reason is that Lang has tests that fail to pass on 1.2 and
>> 1.3; possibly due to bugs in the JVM (time crap). Even once I can make
>> a 1.2/1.3 build, I'm not sure if I should.
>>
>> Plus other reasons, such as being without a happy laptop at home until
>> tonight :)
>>
>>> However, I believe that commons holds an almost unique place in Java
>>> development being the lowest layer in many many open source projects. As
>>> such making an incompatible major version change is a *very* big deal.
>>>
>>> [PROPOSAL]
>>> As such, I would like to propose that projects creating a JDK1.5 only
>>> release should use a new package name. Thus, in this case, the release
>>> would use the package org.apache.commons.net5.*.
>>
>> -1 for a slew of reasons.
>>
>> * Lots of source code would have to be touched just to upgrade; big
>> pain in the arse for something that is quite likely to not involve any
>> other change to a user's source.
>>
>> * Building v49 class files is going to explode on a v48 JVM, so people
>> are going to be stopped pretty quickly from using the net5 on their
>> old JVM. We don't need to protect them via packages.
>>
>> * Do we do net3 and net4 if we move from 1.2 to 1.3/1.4? Do we do net6?
>>
>>> With this change, a user can have both the old and the new commons-net
>>> jars in their classpath without any conflicts.
>>
>> Only a JDK 1.5 user (1.6 too I guess). Presuming we make 1.5 targetted
>> builds and not 1.2->1.4. And then it's nothing to do with 1.4/1.5 and
>> just the classic problem of package clash within dependencies.
>>
>>> Note that these users may be different OSS projects, which may
>>> upgrade at different times.
>>>
>>> Users wishing to migrate from one version to another can simply do a
>>> global search and replace on the package name.
>>>
>>> We must not underestimate the significance of the low-level position of
>>> commons in the Java OSS, and proprietry, communities. A clear and
>>> planned migration strategy for all our modules is needed.
>>
>> I accept that by its nature Commons is going to cause problems every
>> time they release. We're going to be a frequent location for classpath
>> clash problems. It's not JVM relevant though, it happens every time we
>> release anything so the version you would need in the package name is
>> the Commons major version, not the jdk version.
>>
>> I think we should declare that new development will be on 1.5 -
>> building 1.5 only jars. Anyone trying to use them on 1.4 and before is
>> going to get a nice error and we can start exploring new JDK features
>> like regular expressions *sarc :) *. Then we can stick with it until
>> 1.8 is in beta or something.
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Rory Winston <rw...@eircom.net>.
Hey guys
An interesting discussion here. I'll try to address some of the points
raised and give my take on the issue.
* As far as [net] specifically is concerned, there are very few things
that 1.5 makes possible that you really can't do on 1.3 (One of these is
asynchronous I/O and a select()-based thread notification model).
However, 1.5 does make a *ton* of things much cleaner. For instance,
regex support is now on a par with [oro], so we lose our only external
dependency, making [net] a self-contained single jar download. We can
also support secure FTP without having to install a separate JSSE jar,
as SSL/TLS support is now integral in JCE. Apart from that, there are
many, many, smaller enhancements that we can make. See
http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html#2.0
for a few.
* As far as I am concerned, the ideal scenario for a project like [net]
is that 1.5+ support continues on a different version line. It may be
the trunk, it may be a branch. So for [net], the 1.x line is for JDK
1.4.x and below, and the 2.0 line is 1.5+. It doesn't in any way mean
that support is suddenly dropped for pre-Tiger releases. But sooner or
later, 2.0 is the main development version, and that's where the effort
should go.
* I don't like the concept of a ".net5" package name. Does this mean
that we need a ".net6" package space when JDK 6 is released? It doesn't
feel elegant, and it loses one of the big advantages that the current
system has : a user can upgrade their JDK from 1.3 to 5.0 overnight,
download a new [net] 2.0 jar, and their FTPClient-based code should
*just work* (with a 90% probability ;)).
* I agree with Henri's comment below about Commons being a "maintenance"
vs. "development" space. JDK 5.0 has been officially released for around
two years. In my opinion, there shouldn't even be a debate. It should be
taken advantage of, and supported, although not at the expense of
existing users on older versions.
Cheers
Rory
Henri Yandell wrote:
> On 9/9/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
>> Steve Cohen wrote:
>> > I am not ready to vote yet on this until there is a discussion about
>> > what this release means. Will commons-net-2.0 become the "official"
>> > release, with previous versions relegated to "backward compatibility"
>> > support? If so, this may be premature as Sun is still supporting
>> > JDK-1.4.2-x.
>> >
>> > But I don't think we should stand in the way of progress either.
>> Rory,
>> > can you comment on what are the specific new features that demand JDK
>> > 5.0 support?
>> >
>> > How have other jakarta-commons projects handled this? Are there any
>> > official versions that require 1.5? Are there projects that have two
>> > "official" releases?
>>
>> I see this as a positive step (a JDK 1.5 only release).
>> I also see this as the right jump (from JDK 1.2/1.3 to 1.5).
>
> I'm a strong +1 for JDK 1.5 dependence.
>
> The way I see it is that while we're supporting 1.2->1.4, new
> development happens on 1.5 so the only time we need to worry about
> older JVMs is for critical bugfixes on maintenance systems - not for
> new development.
>
> Trying to focus on old JVMs makes us a maintenance project, not a
> development project and that's damaging for the project health.
>
> Lang 2.2 is in a limbo state because I can't get 1.2 for my Mac, I
> need to dig into Ubuntu to try and get it to work there and I can't
> even figure out how to get it to work on Windows at the moment (JDK
> 1.6 appears to be taking over the JAVA_HOME and PATH, but it's not
> defined in the user's environment variables).
>
> Another reason is that Lang has tests that fail to pass on 1.2 and
> 1.3; possibly due to bugs in the JVM (time crap). Even once I can make
> a 1.2/1.3 build, I'm not sure if I should.
>
> Plus other reasons, such as being without a happy laptop at home until
> tonight :)
>
>> However, I believe that commons holds an almost unique place in Java
>> development being the lowest layer in many many open source projects. As
>> such making an incompatible major version change is a *very* big deal.
>>
>> [PROPOSAL]
>> As such, I would like to propose that projects creating a JDK1.5 only
>> release should use a new package name. Thus, in this case, the release
>> would use the package org.apache.commons.net5.*.
>
> -1 for a slew of reasons.
>
> * Lots of source code would have to be touched just to upgrade; big
> pain in the arse for something that is quite likely to not involve any
> other change to a user's source.
>
> * Building v49 class files is going to explode on a v48 JVM, so people
> are going to be stopped pretty quickly from using the net5 on their
> old JVM. We don't need to protect them via packages.
>
> * Do we do net3 and net4 if we move from 1.2 to 1.3/1.4? Do we do net6?
>
>> With this change, a user can have both the old and the new commons-net
>> jars in their classpath without any conflicts.
>
> Only a JDK 1.5 user (1.6 too I guess). Presuming we make 1.5 targetted
> builds and not 1.2->1.4. And then it's nothing to do with 1.4/1.5 and
> just the classic problem of package clash within dependencies.
>
>> Note that these users may be different OSS projects, which may
>> upgrade at different times.
>>
>> Users wishing to migrate from one version to another can simply do a
>> global search and replace on the package name.
>>
>> We must not underestimate the significance of the low-level position of
>> commons in the Java OSS, and proprietry, communities. A clear and
>> planned migration strategy for all our modules is needed.
>
> I accept that by its nature Commons is going to cause problems every
> time they release. We're going to be a frequent location for classpath
> clash problems. It's not JVM relevant though, it happens every time we
> release anything so the version you would need in the package name is
> the Commons major version, not the jdk version.
>
> I think we should declare that new development will be on 1.5 -
> building 1.5 only jars. Anyone trying to use them on 1.4 and before is
> going to get a nice error and we can start exploring new JDK features
> like regular expressions *sarc :) *. Then we can stick with it until
> 1.8 is in beta or something.
>
> Hen
>
> ---------------------------------------------------------------------
> 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
[PROPOSAL] Commons and API change
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Some interesting points have been made so far. I believe I should
restate my proposal based on feedback (especially as the original was
written just after a weeks holiday...):
[PROPOSAL]
Whenever a project performs a backwards incompatible API change, two
things must happen:
a) the major version is increased, eg. from 1.2 to 2.0
b) the package name is changed from o.a.c.foo to o.a.c.foo2, or
alternatively to a completely new name, eg. o.a.c.bar
[/PROPOSAL]
Thus, this isn't really a JDK5 issue, but a basic issue of dependency
management. And hence, as poined out, the API version number should be used.
Note however that it is possible to go up a major version without the
proposed rule being enforced *if* and only if there are no backwards
incompatible changes (removal of deprecations allowed).
Now, I would suggest that many projects going from a JDK1.2/3/4 base to
a JDK1.5 base will want to (and should!) make API changes (also, because
of generics et al its difficult to know if you *have* actually made a
backwards incompatible change!) As such, I would expect these 1.5
projects to be subject to the rule in the proposal.
I understand that this is a bit of a pain for end users, but its a pain
because of the lack of a module system as per JSR277. I would argue that
changing a package name to migrate is infinitely preferable when dealing
with a library to coming up against an insoluble jar hell scenario.
Remember, [collections] took one small human error to cause an
incredible amount of FUD and bad press about commons, that still reduces
our user-base today. *Every* jar-hell scenario that is created worsens
this. AFAIK, package renaming is the best, most-viable solution to
backwards incompatible change in Java today.
Stephen
Henri Yandell wrote:
>> [PROPOSAL]
>> As such, I would like to propose that projects creating a JDK1.5 only
>> release should use a new package name. Thus, in this case, the release
>> would use the package org.apache.commons.net5.*.
>
> -1 for a slew of reasons.
>
> * Lots of source code would have to be touched just to upgrade; big
> pain in the arse for something that is quite likely to not involve any
> other change to a user's source.
>
> * Building v49 class files is going to explode on a v48 JVM, so people
> are going to be stopped pretty quickly from using the net5 on their
> old JVM. We don't need to protect them via packages.
>
> * Do we do net3 and net4 if we move from 1.2 to 1.3/1.4? Do we do net6?
>
>> With this change, a user can have both the old and the new commons-net
>> jars in their classpath without any conflicts.
>
> Only a JDK 1.5 user (1.6 too I guess). Presuming we make 1.5 targetted
> builds and not 1.2->1.4. And then it's nothing to do with 1.4/1.5 and
> just the classic problem of package clash within dependencies.
>
>> Note that these users may be different OSS projects, which may upgrade
>> at different times.
>>
>> Users wishing to migrate from one version to another can simply do a
>> global search and replace on the package name.
>>
>> We must not underestimate the significance of the low-level position of
>> commons in the Java OSS, and proprietry, communities. A clear and
>> planned migration strategy for all our modules is needed.
>
>
> I accept that by its nature Commons is going to cause problems every
> time they release. We're going to be a frequent location for classpath
> clash problems. It's not JVM relevant though, it happens every time we
> release anything so the version you would need in the package name is
> the Commons major version, not the jdk version.
>
> I think we should declare that new development will be on 1.5 -
> building 1.5 only jars. Anyone trying to use them on 1.4 and before is
> going to get a nice error and we can start exploring new JDK features
> like regular expressions *sarc :) *. Then we can stick with it until
> 1.8 is in beta or something.
>
> Hen
>
> ---------------------------------------------------------------------
> 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: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Henri Yandell <fl...@gmail.com>.
On 9/9/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Steve Cohen wrote:
> > I am not ready to vote yet on this until there is a discussion about
> > what this release means. Will commons-net-2.0 become the "official"
> > release, with previous versions relegated to "backward compatibility"
> > support? If so, this may be premature as Sun is still supporting
> > JDK-1.4.2-x.
> >
> > But I don't think we should stand in the way of progress either. Rory,
> > can you comment on what are the specific new features that demand JDK
> > 5.0 support?
> >
> > How have other jakarta-commons projects handled this? Are there any
> > official versions that require 1.5? Are there projects that have two
> > "official" releases?
>
> I see this as a positive step (a JDK 1.5 only release).
> I also see this as the right jump (from JDK 1.2/1.3 to 1.5).
I'm a strong +1 for JDK 1.5 dependence.
The way I see it is that while we're supporting 1.2->1.4, new
development happens on 1.5 so the only time we need to worry about
older JVMs is for critical bugfixes on maintenance systems - not for
new development.
Trying to focus on old JVMs makes us a maintenance project, not a
development project and that's damaging for the project health.
Lang 2.2 is in a limbo state because I can't get 1.2 for my Mac, I
need to dig into Ubuntu to try and get it to work there and I can't
even figure out how to get it to work on Windows at the moment (JDK
1.6 appears to be taking over the JAVA_HOME and PATH, but it's not
defined in the user's environment variables).
Another reason is that Lang has tests that fail to pass on 1.2 and
1.3; possibly due to bugs in the JVM (time crap). Even once I can make
a 1.2/1.3 build, I'm not sure if I should.
Plus other reasons, such as being without a happy laptop at home until
tonight :)
> However, I believe that commons holds an almost unique place in Java
> development being the lowest layer in many many open source projects. As
> such making an incompatible major version change is a *very* big deal.
>
> [PROPOSAL]
> As such, I would like to propose that projects creating a JDK1.5 only
> release should use a new package name. Thus, in this case, the release
> would use the package org.apache.commons.net5.*.
-1 for a slew of reasons.
* Lots of source code would have to be touched just to upgrade; big
pain in the arse for something that is quite likely to not involve any
other change to a user's source.
* Building v49 class files is going to explode on a v48 JVM, so people
are going to be stopped pretty quickly from using the net5 on their
old JVM. We don't need to protect them via packages.
* Do we do net3 and net4 if we move from 1.2 to 1.3/1.4? Do we do net6?
> With this change, a user can have both the old and the new commons-net
> jars in their classpath without any conflicts.
Only a JDK 1.5 user (1.6 too I guess). Presuming we make 1.5 targetted
builds and not 1.2->1.4. And then it's nothing to do with 1.4/1.5 and
just the classic problem of package clash within dependencies.
> Note that these users may be different OSS projects, which may upgrade at different times.
>
> Users wishing to migrate from one version to another can simply do a
> global search and replace on the package name.
>
> We must not underestimate the significance of the low-level position of
> commons in the Java OSS, and proprietry, communities. A clear and
> planned migration strategy for all our modules is needed.
I accept that by its nature Commons is going to cause problems every
time they release. We're going to be a frequent location for classpath
clash problems. It's not JVM relevant though, it happens every time we
release anything so the version you would need in the package name is
the Commons major version, not the jdk version.
I think we should declare that new development will be on 1.5 -
building 1.5 only jars. Anyone trying to use them on 1.4 and before is
going to get a nice error and we can start exploring new JDK features
like regular expressions *sarc :) *. Then we can stick with it until
1.8 is in beta or something.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Brett Porter <br...@apache.org>.
On 10/09/2006, at 12:40 PM, Simon Kitching wrote:
> BTW, It would be great if Java had some other mechanism for handling
> multiple versions of the same library (as Microsoft's CLR has I
> believe)..
As an ASF committer, you are welcome to participate in our
involvement in JSR 277. See http://www.apache.org/jcp/ for details.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2006-09-10 at 00:39 +0100, Stephen Colebourne wrote:
> Steve Cohen wrote:
> [PROPOSAL]
> As such, I would like to propose that projects creating a JDK1.5 only
> release should use a new package name. Thus, in this case, the release
> would use the package org.apache.commons.net5.*.
>
> With this change, a user can have both the old and the new commons-net
> jars in their classpath without any conflicts. Note that these users may
> be different OSS projects, which may upgrade at different times.
As Steve Cohen notes, I'd also be interested to see what features of
commons-net really benefit from a 1.5-compatible release.
However in general it seems a good time for commons to start releasing
code using 1.5 features where there is a benefit to the user. Java 1.5
is now well-established and the features are truly useful.
And I'm +1 to a new package name when doing so (as steve Colebourne
suggests) , to allow the old and new versions to co-exist.
I agree that requiring all apps to have *either* net 1.x or net 2.x in
the path, but not both, will cause a great deal of pain, and will
probably slow the adoption of the new net version.
BTW, It would be great if Java had some other mechanism for handling
multiple versions of the same library (as Microsoft's CLR has I
believe)..
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Steve Cohen wrote:
> I am not ready to vote yet on this until there is a discussion about
> what this release means. Will commons-net-2.0 become the "official"
> release, with previous versions relegated to "backward compatibility"
> support? If so, this may be premature as Sun is still supporting
> JDK-1.4.2-x.
>
> But I don't think we should stand in the way of progress either. Rory,
> can you comment on what are the specific new features that demand JDK
> 5.0 support?
>
> How have other jakarta-commons projects handled this? Are there any
> official versions that require 1.5? Are there projects that have two
> "official" releases?
I see this as a positive step (a JDK 1.5 only release).
I also see this as the right jump (from JDK 1.2/1.3 to 1.5).
However, I believe that commons holds an almost unique place in Java
development being the lowest layer in many many open source projects. As
such making an incompatible major version change is a *very* big deal.
[PROPOSAL]
As such, I would like to propose that projects creating a JDK1.5 only
release should use a new package name. Thus, in this case, the release
would use the package org.apache.commons.net5.*.
With this change, a user can have both the old and the new commons-net
jars in their classpath without any conflicts. Note that these users may
be different OSS projects, which may upgrade at different times.
Users wishing to migrate from one version to another can simply do a
global search and replace on the package name.
We must not underestimate the significance of the low-level position of
commons in the Java OSS, and proprietry, communities. A clear and
planned migration strategy for all our modules is needed.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release [net] version 2.0
Posted by Steve Cohen <sc...@javactivity.org>.
Rory Winston wrote:
> Hi all
>
> I would like to gauge support for a release of Commons::Net 2.0. The
> major changes are:
>
> * FTPS (SSL/TLS) support has been added
> * FTPClient doesnt extend TelnetClient any longer
> * The build now uses Maven 2
> * [net] is now standalone - no external dependencies outside the JDK itself
> * One new FTP parser (Netware) has been added, and the MVS parser has
> been heavily updated
> * A mini "FTP-only" jar (~ 90k) is available for clients who just need
> FTP functionality
> * Deprecated classes and methods have been removed
>
> A full list of changes can be found here:
>
> http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html
>
> I have made the distribution (*unsigned* as yet) available for inspection:
>
> http://people.apache.org/~rwinston/commons-net-2.0/
>
> And the site is available:
>
> http://people.apache.org/~rwinston/commons-net-2.0/site/
>
>
> Thanks
> Rory
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
I am not ready to vote yet on this until there is a discussion about what this
release means. Will commons-net-2.0 become the "official" release, with
previous versions relegated to "backward compatibility" support? If so, this
may be premature as Sun is still supporting JDK-1.4.2-x.
But I don't think we should stand in the way of progress either. Rory, can you
comment on what are the specific new features that demand JDK 5.0 support?
How have other jakarta-commons projects handled this? Are there any official
versions that require 1.5? Are there projects that have two "official" releases?
Steve Cohen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release [net] version 2.0
Posted by Rory Winston <rw...@eircom.net>.
Not in this release, but it's possible that the interface could be
changed from FTPFile[] to List<FTPFile> at some stage. This would affect
a lot of existing client code, though. I don't see a huge benefit
either, seeing as you can just do an Arrays.asList() in the current
code, if desired.
Cheers
R
jieryn@gmail.com wrote:
>> I would like to gauge support for a release of Commons::Net 2.0. The
>> major changes are:
>
> Is there any plans to move to java.util.Collection classes?
> Specifically, I'd love to see us move away from the FTPFile [] type
> things in favor of Collection<FTPFile>.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [VOTE] Release [net] version 2.0
Posted by Jared Graber <jg...@zedak.com>.
Sorry, my mistake.
I guess I'll be sticking w/ Commons Net 1.4.1 for a while then. :(
-Jared
-----Original Message-----
From: jieryn@gmail.com [mailto:jieryn@gmail.com]
Sent: Friday, September 08, 2006 2:57 PM
To: Jakarta Commons Users List
Subject: Re: [VOTE] Release [net] version 2.0
> Unfortunately many companies in the corporate world use older Application
> Servers (even for new projects). I think it is necessary at this time to
> have a version of the library that isn't dependant upon Java 1.5.
Commons-Net-2.0.0 is already dependent on Java 1.5.
-Jesse
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VOTE] Release [net] version 2.0
Posted by ji...@gmail.com.
> Unfortunately many companies in the corporate world use older Application
> Servers (even for new projects). I think it is necessary at this time to
> have a version of the library that isn't dependant upon Java 1.5.
Commons-Net-2.0.0 is already dependent on Java 1.5.
-Jesse
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [VOTE] Release [net] version 2.0
Posted by Jared Graber <jg...@zedak.com>.
I think that would cause problems for a lot of people that still develop
using Java 1.4 unless there were just different versions of the library for
different versions of java.
Unfortunately many companies in the corporate world use older Application
Servers (even for new projects). I think it is necessary at this time to
have a version of the library that isn't dependant upon Java 1.5.
-Jared
-----Original Message-----
From: jieryn@gmail.com [mailto:jieryn@gmail.com]
Sent: Friday, September 08, 2006 12:51 PM
To: Jakarta Commons Users List
Subject: Re: [VOTE] Release [net] version 2.0
> I would like to gauge support for a release of Commons::Net 2.0. The
> major changes are:
Is there any plans to move to java.util.Collection classes?
Specifically, I'd love to see us move away from the FTPFile [] type
things in favor of Collection<FTPFile>.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VOTE] Release [net] version 2.0
Posted by ji...@gmail.com.
> I would like to gauge support for a release of Commons::Net 2.0. The
> major changes are:
Is there any plans to move to java.util.Collection classes?
Specifically, I'd love to see us move away from the FTPFile [] type
things in favor of Collection<FTPFile>.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org