Has commons net 3.3 been released ?

[Oberhuber, Martin]

Hi all,

Looking at the commons net release notes:
http://commons.apache.org/proper/commons-net/changes-report.html
I see that release 3.3 is TBA, but looking at the downloads page:
   http://commons.apache.org/proper/commons-net/download_net.cgi
I see a commons net 3.3 download.

Since I'm not aware that commons net 3.3 had been officially announced on this 
list,
I assume that the downloads page should talk about "net 3.3 SNAPSHOT" instead ?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

RE: [NET] 3.2 ready?

[Oberhuber, Martin]

NET-466 has been fixed (thanks!), so could a release be cut ?

Commons Net 3.1 is unusable for us due to NET-466.

I've seen an offer for providing a patch to NET-481; just contacted the 
submitter.
 
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6


-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Tuesday, July 24, 2012 11:13 PM
To: Commons Developers List
Subject: Re: [NET] 3.2 ready?

On 23 July 2012 07:41, Gary Gregory  wrote:
> Hi All,
>
> How close are we to releasing 3.2?

There are some outstanding JIRA issues that it would be good to address, e.g.

NET-466

I've not had time to look at this.

> I just tried a local build and the reports look pretty good.
>
> How about removing @author tags? Clean up of @version tags?
>

@version tags are already OK (no $Date).

> Thank you,
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 
> 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

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


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

RE: [NET] SFTP vs. FTPS

[Oberhuber, Martin]

Hi Steve,

sftp is a sub-specification of the SSH protocol (you'll surely
find the RFC or just
  http://en.wikipedia.org/wiki/SSH_file_transfer_protocol 
As for a Java library, Eclipse has been using
  http://www.jcraft.com/jsch/
for years in order to provide the SSH channel for CVS, and since
3 years I'm successfully using the same library to run sftp inside 
Eclipse as part of my project
  http://www.eclipse.org/dsdp/tm

I've been told that there's another Java library for SSH
(Ganymed) and some claim it's better, but I haven't looked
at it
  http://www.ganymed.ethz.ch/ssh2/
I believe at Eclipse we couldn't use this since it seems to
include all cryptographic code and Eclipse can't just go
ship / export crypto code that easily.


Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Steve Cohen [mailto:sco...@javactivity.org] 
> Sent: Mittwoch, 13. Mai 2009 18:37
> To: Commons Developers List
> Subject: [NET] SFTP vs. FTPS
> 
> Hi.
> 
> I've been out of the FTP "game" for several years and now I 
> need to get 
> back in.  I have a requirement to set up a secure FTP connection with 
> another organization, so naturally, I look to commons-net first as a 
> solution.  I notice that there is support for FTPS in commons-net but 
> not for SFTP.
> 
> Not being up on the latest buzz on this "controversy", I wonder if 
> someone can point me at a good discussion of the differences, 
> why we are 
> implementing one and not the other, etc.  Also, if I will be 
> required to 
> use SFTP (not sure yet), is there an open-source java package 
> out there 
> similar to commons-net that supports it?
> 
> Thanks.
> 
> Steve Cohen
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 

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

RE: [net] 2.0 Release Ready For Review

[Oberhuber, Martin]

> Also, the binary jar contains an examples/ directory, but it contains
> only the class files.
> 
> Surely it should contain the source files instead?

I'm not sure about best practices used in Apache Commons, but
it seems odd to me that examples code is even found in the
binary jar.

Shouldn't the binary jar be ready for deployment into client
applications? Doesn't seem like source code or an examples/
package is right in something to be deployed.

I'd rather put the examples into a separate Jar of their own,
but again I'm not sure what other Commons projects do?

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: sebb [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, September 18, 2008 4:05 PM
> To: Commons Developers List
> Subject: Re: [net] 2.0 Release Ready For Review
> 
> Also, the binary jar contains an examples/ directory, but it contains
> only the class files.
> 
> Surely it should contain the source files instead?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [net] 2.0 Release Ready For Review

[Oberhuber, Martin]

> has anybody ever tried
> 
>   javac -target 1.4 -bootclasspath ${JAVA14_HOME}/lib/rt.jar
> 
> on commons net 2.0?

I just did a quick check, and it looks like this question was
silly (sorry). Apparently, using java -target 1.4 also requires
java -source 1.4 which would fail due to all the Generics and
Annotations in the code.

It does seem, though, that any adopter of Commons Net 2.0 could
use Retroweaver to change the Commons Net bytecode into something
that an 1.4 JVM can understand -- and it should work quite fine 
since it looks like the usage of "enum" in examples/TftpServer.java
is the only real dependency on an 1.5-only class ("Enum" which is
emulated by Retroweaver):
http://retroweaver.sourceforge.net/

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
> 
> Cheers,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
>  
>  
> 
> > -Original Message-
> > From: Rory Winston [mailto:[EMAIL PROTECTED] 
> > Sent: Thursday, September 18, 2008 8:53 AM
> > To: Jakarta Commons Developers List
> > Subject: [net] 2.0 Release Ready For Review
> > 
> > Hi all
> > 
> > The RC for net-2.0 is available for review at:
> > 
> > http://people.apache.org/~rwinston/commons-net-2.0
> > 
> > Changes are here:
> > 
> > http://people.apache.org/~rwinston/commons-net-2.0/site/change
> > s-report.html#a2.0
> > 
> > Can someone take a look at the RC and see if there are any 
> issues? If 
> > not, I'll set up a  release vote.
> > 
> > Thanks
> > Rory
> > 
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [net] 2.0 Release Ready For Review

[Oberhuber, Martin]

Hi Rory,

thanks for taking the time putting this together.

I just notice that in the changes list, some entries
seem to be broken off unexpectedly:

  "SSLServerSocketFactory. Thanks "   //Thanks WHOM?
  "updated MVSFTPEntryParser from "   //from WHERE?

Perhaps some XML escaping is missing here?
http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.h
tml#a2.0

In the commons-net-2.0.0.jar / META-INF I see that
there are also maven/.../pom.xml and maven/.../pom.properties
is that intended?

Given that Commons Net 2.0 requires Java 1.5, I'm missing a
   Bundle-RequiredExecutionEnvironment: J2SE-1.5
statement in the META-INF/MANIFEST.MF -- BTW is it actually
true that it requires 1.5 at runtime, or is it just using 1.5
source format such that it could even run with an 1.4 runtime
if compiled into 1.4 classfile format? I know that it requires
Java 1.4 java.util.regex but was not so sure about 1.5 
requirements... has anybody ever tried

  javac -target 1.4 -bootclasspath ${JAVA14_HOME}/lib/rt.jar

on commons net 2.0?

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Rory Winston [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, September 18, 2008 8:53 AM
> To: Jakarta Commons Developers List
> Subject: [net] 2.0 Release Ready For Review
> 
> Hi all
> 
> The RC for net-2.0 is available for review at:
> 
> http://people.apache.org/~rwinston/commons-net-2.0
> 
> Changes are here:
> 
> http://people.apache.org/~rwinston/commons-net-2.0/site/change
> s-report.html#a2.0
> 
> Can someone take a look at the RC and see if there are any issues? If 
> not, I'll set up a  release vote.
> 
> Thanks
> Rory
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Net 1.5 / 2.0 Releases

[Oberhuber, Martin]

Right,

since there seems some community need for this, 
I'm not going to stand in its way.

Thanks for working towards a release!

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Niklas Gustavsson [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, August 26, 2008 8:27 AM
> To: Commons Developers List
> Subject: Re: Commons Net 1.5 / 2.0 Releases
> 
> On Tue, Aug 26, 2008 at 12:07 AM, Rory Winston 
> <[EMAIL PROTECTED]> wrote:
> > Niklas Gustavsson wrote:
> >>
> >> On Mon, Aug 25, 2008 at 3:05 PM, Oberhuber, Martin
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >>>
> >>> The backward compatibility question you mention was about the
> >>> suggestion to refactor the Commons Net "small protocol"
> >>> implementations into separate packages each:
> >>>
> >>
> >> Oh, that was not my understanding. But since there hasn't 
> been such a
> >> change (besides to separate FTP client JAR) I guess we're 
> good to go
> >> in this aspect.
> >
> > This change was done months ago (for 2.0 at least).
> 
> Re-reading the thread I see that I completely misunderstood Martins
> email. Rory is of course correct, for the clients listed by Niall
> previously, they have been moved into their own packages. The same way
> as the other clients, like FTP and SMTP did before. Now that Martin
> seems fine with this change I guess we can go ahead.
> 
> /niklas
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Net 1.5 / 2.0 Releases

[Oberhuber, Martin]

Thanks Niklas.

The backward compatibility question you mention was about the
suggestion to refactor the Commons Net "small protocol" 
implementations into separate packages each:

> Basically there's no problem to deliver a 
> commons-net-2.0-legacy.jar that contains something along
> 
> package org.apache.commons.net;
> class Echo extends org.apache.commons.net.echo.Echo { ... };
> 
> > I'm all in favor of code cleanup and refactoring when
> > I see clear advantages, but not at any price.

I was not in favor of such a costly, breaking change which
doesn't buy much, so I'd vote for going forward towards
a release. Can you put up a release candidate?

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Niklas Gustavsson [mailto:[EMAIL PROTECTED] 
> Sent: Friday, August 22, 2008 4:46 PM
> To: Commons Developers List
> Subject: Re: Commons Net 1.5 / 2.0 Releases
> 
> On Tue, May 27, 2008 at 11:31 AM, Niklas Gustavsson
> <[EMAIL PROTECTED]> wrote:
> > On Thu, May 22, 2008 at 8:02 AM, Niklas Gustavsson 
> <[EMAIL PROTECTED]> wrote:
> >> On Wed, May 21, 2008 at 11:27 PM, Rory Winston 
> <[EMAIL PROTECTED]> wrote:
> >>> I meant to say "out of the project". It was moved to 
> test/ after the
> >>> discussion.
> >>
> >> Great, so it seems we agree :-) However, the class is still in
> >> src/main, not in src/test:
> >> 
> http://svn.apache.org/repos/asf/commons/proper/net/branches/NE
> T_2_0/src/main/java/org/apache/commons/net/tftp/TFTPServer.java
> >>
> >> Should I move it to the test directory?
> >
> > If no one objects I'll go ahead and move it to src/test.
> 
> Alright, better later than never I guess. As no one objected, I'll go
> ahead and commit that change.
> 
> Is there anything else that would be needed before a 2.0 release?
> Previously in this thread there was some discussions around backward
> compatibility, but no conclusion seems to been reached. Do we need to
> discuss this further?
> 
> /niklas
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Compress vs. VFS

[Oberhuber, Martin]

Hello Christian,

many thanks, that's very interesting information indeed.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Christian Grobmeier [mailto:[EMAIL PROTECTED] 
> Sent: Monday, July 07, 2008 2:18 PM
> To: Commons Developers List
> Subject: Re: Compress vs. VFS
> 
> Hi Martin,
> we would like to have an own apache component,
> cause several people here do not like the api.
> As stated in the board report of september 07,
> they is less community behind truezip, which is another -.
> However, if interested, check these discussions here:
> http://markmail.org/search/?q=TrueZip%20list%3Aorg.apache.comm
> ons.dev%2F
> 
> There was also a discussion about a TrueZip provider for VFS,
> but i don't mind if that happened.
> See: http://issues.apache.org/jira/browse/VFS-106
> 
> Best,
> Chris
> 
> On Mon, Jul 7, 2008 at 11:34 AM, Oberhuber, Martin <
> [EMAIL PROTECTED]> wrote:
> 
> > Hello Samuel, Mario and others,
> >
> > if just interested in accessing ZIP files, have you
> > had a look at TrueZip:
> >  https://truezip.dev.java.net/
> >
> > It might make sense to provide a TrueZip wrapper for
> > Commons VFS eventually.
> >
> > How do the Commons Compress folk compare to TrueZip?
> >
> > Cheers,
> > --
> > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Compress vs. VFS

[Oberhuber, Martin]

Hello Samuel, Mario and others,

if just interested in accessing ZIP files, have you
had a look at TrueZip:
  https://truezip.dev.java.net/

It might make sense to provide a TrueZip wrapper for
Commons VFS eventually.

How do the Commons Compress folk compare to TrueZip?

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: RShell:All ports in use or insufficient permssion.

[Oberhuber, Martin]

Hi,

it is a restriction by design of rlogin / rsh that the client
port must be in the "restricted ports" area < 1024, which only 
the root user may open.

I assume the reason for this is, that through the rsh 
protocol, if user x has set up a .rhosts file for his
account, then user y could "spoof" the system by making
the remote think he were x.

UNIX systems fix this by making the rsh program run with
"setuid" permissions, that is non-root clients can call
the rsh program which then executes with root permissions.

In your concrete situation, I would recommend that you either
call the external rsh binary program from Java (thus inheriting
the root permission via the setuid bit), or you switch to
using a Java SSH client such as JSch.

References:
http://en.wikipedia.org/wiki/Remote_Shell
http://en.wikipedia.org/wiki/Rlogin
http://tools.ietf.org/html/rfc1282
http://www.jcraft.com/jsch/index.html

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Friday, June 13, 2008 10:19 AM
> To: dev@commons.apache.org
> Subject: RShell:All ports in use or insufficient permssion.
> 
> Hi,
> 
> I want to invoke a command in a remote machine using 
> RSh(remote shell) from my java app, so I'm trying out the 
> examples.rshell class in commons-net-1.4.1.
> The only way it succeeded was running the Java app from 
> linux(as root) to linux, but my app will not be run as root, 
> and I must invoke a command using rsh.
> From the linux shell, it works fine using the rsh command 
> from non-root user to a non-root user in other linux machine. 
> The command is like this one:
>     rsh -l myuser remoteIP "ls -l"
> 
> The question is: Why must it be run as root the 
> examples.rshell class if linux OS allows me to do it as 
> non-root from the command shell? Can I get it not being root 
> in the source machine? 
> 
> As I've seen in the code, it limits itself and throws an exception:
>     if (localPort < MIN_CLIENT_PORT)
>     throw new BindException("All ports in use or 
> insufficient permssion.");
> 
> Thanks!
> 
> 
> 
>   __ 
> Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [g...@vmgump]: Project commons-net (in module apache-commons) failed

[Oberhuber, Martin]

Hi all,

Is anybody addressing this Gump Nag message for commons-net
already:

>  -ERROR- Bad Dependency. Project: xml-apis : unknown to 
> *this* workspace 

I cannot understand how or why commons-net would even
reference xml-apis?

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 19, 2008 6:09 AM
> Subject: [EMAIL PROTECTED]: Project commons-net (in module 
> apache-commons) failed
> 
>
http://vmgump.apache.org/gump/public/apache-commons/commons-net/index.ht
ml
> 
>  -ERROR- Bad Dependency. Project: xml-apis : unknown to 
> *this* workspace 
>  -DEBUG- Extracted fallback artifacts from Gump Repository

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Net 1.5 / 2.0 Releases

[Oberhuber, Martin]

Hi Jörg,

Good point -- but in my environment (Eclipse), transitive
Deps are a non-issue since OSGi provides multiple classloaders
So I can live with ACN 1.5 and 2.0 at the same time even if
They have mutually incompatible implementations of the same
Class in the same namespace.

I'd rather like to have the ability to choose ACN 1.5 or
2.0 when my app happens to use only such parts of the lib
That happen to have changed in a non-breaking manner.
I cannot see why moving to Java5 forces binary breaking 
Changes -- after all the Java5 collections can be called
>From older Java too thanks to the concept of Erasures.

Of course I'm not talking about forced backward compatibility
In all cases. This is a major release, and it's one for good
Reason. I'm just talking about not breaking compatibility
Unless there is good reason for doing so.

And refactoring those small protocol impls into separate
Namespaces each is not a good reason IMHO. But perhaps
Somebody could argue to convince me why this is a good
And important thing?

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Jörg Schaible [mailto:[EMAIL PROTECTED] 
> Sent: Mittwoch, 21. Mai 2008 07:55
> To: Commons Developers List
> Subject: RE: Commons Net 1.5 / 2.0 Releases
> 
> Hi Martin,
> 
> Oberhuber, Martin wrote:
> > Hi Rory,
> > 
> > Thanks for your opinion -- but may I note that even if
> > It's a major releases, there may be (some|many) existing
> > Clients which are not broken even if they upgrade,
> > Depending on what APIs their client code currently uses.
> > 
> > Breaking clients for no good reason just isn't playing
> > Nice with the clients IMHO, although you are right that
> > You do have the chance doing so in a major release.
> > 
> > At any rate, I wouldn't call the discussion irrelevant.
> > It is relevant for clients picking up commons net when
> > They migrate from 1.x to 2.x, and depending on what
> > The clients do and how many different ones there are,
> > Even Eclipse Ctrl+Shift+O can sum up to a non-trivial
> > Amount of total work on behalf of the clients.
> 
> Basically there's no problem to deliver a 
> commons-net-2.0-legacy.jar that contains something along
> 
> package org.apache.commons.net;
> class Echo extends org.apache.commons.net.echo.Echo { ... };
> 
> > I'm all in favor of code cleanup and refactoring when
> > I see clear advantages, but not at any price.
> > 
> > For our FTP clients, I'd love to see customers being
> > Able to exchange net 1.5 against net 2.0 pre-compiled
> > Binaries in the final product if possible.
> 
> However, this implies that ACN 1.x is binary compatible to 
> ACN 2.0. However that is simply neither guaranteed nor 
> enforced. If ACN 2.x makes usage of Java 5 you will see some 
> API breakage that prohibits 2.x to be used as drop in 
> replacement. That was simply not the goal of this design. 
> However that's the reason why *I* always recommend to use a 
> different package name for major releases with API breakage, 
> simply to ensure that both versions can be used at the same 
> time. Not that a client wants to do this, but he might be 
> forced to do so because of transitive deps.
> 
> - Jörg
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vfs] vfs2 or plain wrapper mode

[Oberhuber, Martin]

Hi Mario,

Just wondering, how would a client of VFS enumerate
Just the folders in a directory e.g. in order to
Render a tree of files?

He needs to know here what items are folders and
What items are files (which gets more difficulte
When symbolic links with file-flavor or folder-flavor
Are involved, or archives like ZIP and TAR that 
Can present virtual subfolders).

Thoughts?

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Mario Ivankovits [mailto:[EMAIL PROTECTED] 
> Sent: Mittwoch, 21. Mai 2008 14:45
> To: Jakarta Commons Developers List
> Subject: [vfs] vfs2 or plain wrapper mode
> 
> Hi!
> 
> Probably I find some time during the next weekend to fix a 
> long standig
> bug in VFS regarding dealing with hidden or special files.
> 
> The main problem I see is that VFS tries to act more like a real
> filesystem than a simple wrapper.
> VFS tries to determine the filetype (FILE, DIR, VIRTUAL) and 
> then throws
> an exception if one tries to open a VIRTUAL file. VFS thinks 
> such a file
> can not exist.
> 
> I'd like to change that behavior from a "fail fast" to a "fail lazy"
> one, means, even on VIRTUAL files VFS tries to issue a 
> getInputStream()
> on read. If the underlaying library then throws an exception about
> non-existent files this exception will be converted to a VFS 
> exception.
> 
> The internal file-type is then more like a "guess" and might change on
> e.g. getInputStream(). For example, a VIRTUAL file will 
> become a FILE if
> getInputStream() succeeded.
> 
> In the end I'd like to make VFS behave more like a wrapper than a real
> filesystem and VFS will pass down each file operation to the 
> underlaying
> library as soon as possible and then normalize the thrown 
> exceptions to
> VFS ones if possible.
> 
> As a side-effect it could be possible to disable this filetype
> determination at all (or make it optional) and thus make VFS a lot
> faster e.g. with FTP connections where this operation is really really
> costly.
> 
> As far as I can see this will lead to a somehow different behavior of
> VFS than it is today. It should not influence any existing 
> applications,
> but it might.
> So, my questions are:
> * [ ] Do you agree that such an evolution might make sense
> * and if so, should I
> ** [ ] add a VFS-global (static) flag to enable this 
> wrapper-like-mode or
> ** [ ] can I fork VFS to put the current head into 
> maintainance (or more
> correct "dormant") mode and start with e.g. VFS 2.0?
> 
> I'd prefer VFS 2.0.
> 
> Ciao,
> Mario
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Net 1.5 / 2.0 Releases

[Oberhuber, Martin]

Hi Rory,

Thanks for your opinion -- but may I note that even if
It's a major releases, there may be (some|many) existing
Clients which are not broken even if they upgrade,
Depending on what APIs their client code currently uses.

Breaking clients for no good reason just isn't playing
Nice with the clients IMHO, although you are right that
You do have the chance doing so in a major release.

At any rate, I wouldn't call the discussion irrelevant.
It is relevant for clients picking up commons net when
They migrate from 1.x to 2.x, and depending on what
The clients do and how many different ones there are,
Even Eclipse Ctrl+Shift+O can sum up to a non-trivial
Amount of total work on behalf of the clients.

I'm all in favor of code cleanup and refactoring when 
I see clear advantages, but not at any price.

For our FTP clients, I'd love to see customers being
Able to exchange net 1.5 against net 2.0 pre-compiled
Binaries in the final product if possible.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Rory Winston [mailto:[EMAIL PROTECTED] 
> Sent: Mittwoch, 21. Mai 2008 00:57
> To: Commons Developers List
> Subject: Re: Commons Net 1.5 / 2.0 Releases
> 
> Can I just add, it's a major release (1.5 -> 2.0).
> 
> 
> Rory Winston wrote:
> > This is totally irrelevant. It's called refactoring.
> >
> >
> > Oberhuber, Martin wrote:
> >> I agree that I cannot see a strong argument for such a
> >> Breaking change. In general, binary backward compatibility
> >> For a lib with such a wide distribution should be maintained
> >> If there are no strong arguments against maintaining it.
> >>
> >> In this case, it looks like the various clients are small
> >> Enough to live in a single package.
> >>
> >> Cheers,
> >> -- 
> >> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> >> Target Management Project Lead, DSDP PMC Member
> >> http://www.eclipse.org/dsdp/tm
> >>  
> >>  
> >>
> >>  
> >>> -Original Message-
> >>> From: Rory Winston [mailto:[EMAIL PROTECTED] Sent: 
> Montag, 19. 
> >>> Mai 2008 23:19
> >>> To: Commons Developers List
> >>> Subject: Re: Commons Net 1.5 / 2.0 Releases
> >>>
> >>> I think this was just a logical reorganization of the 
> source code. A 
> >>> lot of stuff was bundled in together that probably should 
> have been 
> >>> in separate packages for clarity in the first place. I dont think 
> >>> these classes are widely used at all. If they are, its a pretty 
> >>> simple matter to fix (CTRL+SHIFT+O in Eclipse will fix it 
> instantly, 
> >>> for instance).
> >>>
> >>> Rory
> >>>
> >>> Niall Pemberton wrote:
> >>>
> >>>> >From a quick scan of Net 2.0 the there has been the following
> >>>> re-organization in Net 2.0:
> >>>>
> >>>> o.a.c.n.CharGenTCPClient moved to o.a.c.n.chargen package
> >>>> o.a.c.n.CharGenUDPClient moved to o.a.c.n.chargen package
> >>>> o.a.c.n.DaytimeTCPClient moved to o.a.c.n.daytime package
> >>>> o.a.c.n.DaytimeUDPClient moved to o.a.c.n.daytime package
> >>>> o.a.c.n.DiscardTCPClient moved to o.a.c.n.discard package
> >>>> o.a.c.n.DiscardUDPClient moved to o.a.c.n.discard package
> >>>> o.a.c.n.EchoTCPClient moved to o.a.c.n.echo package
> >>>> o.a.c.n.EchoUDPClient moved to o.a.c.n.echo package
> >>>> o.a.c.n.FingerClient moved to o.a.c.n.finger package
> >>>> o.a.c.n.TimeTCPClient moved to o.a.c.n.time package
> >>>> o.a.c.n.TimeUDPClient moved to o.a.c.n.time package
> >>>> o.a.c.n.WhoisClient moved to o.a.c.n.whois package
> >>>>
> >>>> Are these package moves necessary - looks like were just going to
> >>>> inflict unecessary pain on the users? If the Net devs 
> still   
> >>> think its
> >>>
> >>>> a good idea, then it would provide users with an upgrade 
> path if the
> >>>> the new packages are added in Net 1.5 and the old classes   
> >>> with the old
> >>>
> >>>> package names deprecated.
> >>>>
> >>>> Niall
> >>>>
> >>>> On Mon, May 19, 2008 at 6:29 PM, Niklas Gustavsson   
> >>>

RE: [NET] Tabs and spaces

[Oberhuber, Martin]

Is there any guideline on tabs vs spaces in Commons?

Given that due to the Copyright Text Change we have
A diff on each and every file already, now might be
A good time to do such a global cleanup, in order
To simplify diffs / patches in upcoming bugfix 
Releases, and cross-porting patches between the 
1.5 and 2.0 streams.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Dennis Lundberg [mailto:[EMAIL PROTECTED] 
> Sent: Montag, 19. Mai 2008 19:54
> To: Commons Developers List
> Subject: Re: [NET] Tabs and spaces
> 
> sebb wrote:
> > Looks like most of NET uses spaces for indentation.
> > 
> > [There are about 28,000 lines starting with 4 or more spaces; only
> > about 2,000 lines starting with tab]
> > 
> > However, there are quite a few files that use tabs; it 
> looks like the
> > assumption is that tabs are every 4 spaces - but of course 
> this is not
> > necessarily how all editors and printers are set up...
> > 
> > Any views on fixing these?
> 
> I'd replace each tab with 4 spaces.
> 
> > I'm happy to do this.
> > 
> > I noticed the problem when creating some patches for NET.
> > 
> > S///
> > 
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> 
> -- 
> Dennis Lundberg
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Net 1.5 / 2.0 Releases

[Oberhuber, Martin]

I agree that I cannot see a strong argument for such a
Breaking change. In general, binary backward compatibility
For a lib with such a wide distribution should be maintained
If there are no strong arguments against maintaining it.

In this case, it looks like the various clients are small
Enough to live in a single package.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Rory Winston [mailto:[EMAIL PROTECTED] 
> Sent: Montag, 19. Mai 2008 23:19
> To: Commons Developers List
> Subject: Re: Commons Net 1.5 / 2.0 Releases
> 
> I think this was just a logical reorganization of the source 
> code. A lot 
> of stuff was bundled in together that probably should have been in 
> separate packages for clarity in the first place. I dont think these 
> classes are widely used at all. If they are, its a pretty 
> simple matter 
> to fix (CTRL+SHIFT+O in Eclipse will fix it instantly, for instance).
> 
> Rory
> 
> Niall Pemberton wrote:
> > >From a quick scan of Net 2.0 the there has been the following
> > re-organization in Net 2.0:
> >
> > o.a.c.n.CharGenTCPClient moved to o.a.c.n.chargen package
> > o.a.c.n.CharGenUDPClient moved to o.a.c.n.chargen package
> > o.a.c.n.DaytimeTCPClient moved to o.a.c.n.daytime package
> > o.a.c.n.DaytimeUDPClient moved to o.a.c.n.daytime package
> > o.a.c.n.DiscardTCPClient moved to o.a.c.n.discard package
> > o.a.c.n.DiscardUDPClient moved to o.a.c.n.discard package
> > o.a.c.n.EchoTCPClient moved to o.a.c.n.echo package
> > o.a.c.n.EchoUDPClient moved to o.a.c.n.echo package
> > o.a.c.n.FingerClient moved to o.a.c.n.finger package
> > o.a.c.n.TimeTCPClient moved to o.a.c.n.time package
> > o.a.c.n.TimeUDPClient moved to o.a.c.n.time package
> > o.a.c.n.WhoisClient moved to o.a.c.n.whois package
> >
> > Are these package moves necessary - looks like were just going to
> > inflict unecessary pain on the users? If the Net devs still 
> think its
> > a good idea, then it would provide users with an upgrade path if the
> > the new packages are added in Net 1.5 and the old classes 
> with the old
> > package names deprecated.
> >
> > Niall
> >
> > On Mon, May 19, 2008 at 6:29 PM, Niklas Gustavsson 
> <[EMAIL PROTECTED]> wrote:
> >   
> >> I would prefer to get 2.0 out there as well. I would 
> rather see us be
> >> fixing bugs as found by users than keeping it around for 
> even longer
> >> in the current state. It's time to get it out there.
> >>
> >> /niklas
> >>
> >> On Mon, May 19, 2008 at 6:35 PM, sebb <[EMAIL PROTECTED]> wrote:
> >> 
> >>> I think 1.5 is closer to being ready for a release than 2.0.
> >>>
> >>> Given that any bugs that are found in 1.5 are probably going to be
> >>> present in 2.0 as well, I would like to suggest that 1.5 
> is released
> >>> first, and 2.0 after there has been some time for people 
> to use 1.5 in
> >>> earnest.
> >>>
> >>> Are there any JIRA issues which still need to be fixed for 1.5?
> >>>
> >>>
> >>> On 17/05/2008, Rory Winston <[EMAIL PROTECTED]> wrote:
> >>>   
> >>>> Martin/Sebb
> >>>>
> >>>>  Are we ready to cut another RC? I can do so if you guys 
> are happy with
> >>>> where we're at.
> >>>>
> >>>>  Rory
> >>>>
> >>>>
> >>>>  Oberhuber, Martin wrote:
> >>>>
> >>>> 
> >>>>> Hi all,
> >>>>>  just wondering, what's currently holding off a release 
> of Commons Net
> >>>>> 1.5 / 2.0?
> >>>>>  Many issues have been sorted out after the last 
> release candidates, when
> >>>>> can
> >>>>> we expect a new RC to review? Is there anything 
> particular that I could
> >>>>> help
> >>>>> with?
> >>>>>  Cheers,
> >>>>> --
> >>>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> >>>>> Target Management Project Lead, DSDP PMC Member
> >>>>> http://www.eclipse.org/dsdp/tm
> >>>>>
> >>>>>
> >>>>>
> >>>>>   
> >>>> 
> 

Commons Net 1.5 / 2.0 Releases

[Oberhuber, Martin]

Hi all,
 
just wondering, what's currently holding off a release of Commons Net
1.5 / 2.0?
 
Many issues have been sorted out after the last release candidates, when
can
we expect a new RC to review? Is there anything particular that I could
help
with?
 
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

RE: GSoC application

[Oberhuber, Martin]

Just in case you folks have not noticed...

Google has some swag (T-shirts and the like) for those
Students who have not been accepted but decide to do
Their project anyways.

I just read this on IRC but I'm not sure what the process
Is for receiving the swag.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Daniel F. Savarese [mailto:[EMAIL PROTECTED] 
> Sent: Mittwoch, 23. April 2008 17:48
> To: Jakarta Commons Developers List
> Subject: Re: GSoC application 
> 
> 
> In message <[EMAIL PROTECTED]>, 
> Torsten Curdt wri
> tes:
> >On Apr 22, 2008, at 21:48, Daniel F. Savarese wrote:
> >> Is there any particular reason why he can't work on the project  
> >> anyway?
> >
> >Of course not ...you are mote than welcome to contribute :)
> 
> I'm assuming you intended a generic you and not a specific you
> (i.e., me).  I wasn't the one who made the proposal and am already
> a committer, so only a generic you would make any sense (i.e.,
> "anyone is welcome to contribute").
> 
> In case my attempt to be helpful has been misunderstood, I'll 
> disambiguate.
> As a fellow PMC member (and part of the role of the PMC is to build
> community), I was highlighting that merely because GSoC isn't able
> to provide funding for someone to work on some part of Commons doesn't
> mean that person cannot still be encouraged to participate.  
> Consequently,
> I am pointing out that the option of inviting Hao Zheng to 
> contribute to
> Commons Configuration anyway appears to have not been explored.  If I
> believed it were appropriate for me to extend that 
> invitation, I would have
> done so instead of pointing out that it was an option that 
> could be pursued.
> 
> daniel
> 
> o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o 
> o-o-o-o-o-o-o-o-o-o-o-o-o-o
> Igfip  os a v a r e s e
> The strategic alternative for online games(tm).o   software research
> http://www.igfip.com/  o 
> http://www.savarese.com/
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Releasing Commons Net 1.5

[Oberhuber, Martin]

> > I have a patch available for adding file permission support
> > to the VMSEntryParser, in case anybody is interested --
> > it's not critical, though.
> 
> Perhaps create a JIRA enhancement and attach it?

Done, 
https://issues.apache.org/jira/browse/NET-214

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Releasing Commons Net 1.5

[Oberhuber, Martin]

Hi Rory et al,
 
I've been looking at the fixes that have been applied to the 
Commons Net 1.5 branch recently, and they all look good
to me.
 
Attached is a patch to fix the changelog for 1.5.
 
I have a patch available for adding file permission support
to the VMSEntryParser, in case anybody is interested --
it's not critical, though.
 
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 
Index: xdocs/changes.xml
===
--- .   (revision 637090)
+++ .   (working copy)
@@ -92,6 +92,24 @@
Article.java: Fix minor issues with NNTP
 parsing.

+   
+   NtpV3Impl.java: Avoid double-checked locking
+   
+   
+   FTPFileEntryParserImpl.java: Fix Javadoc for 
preParse()
+   
+   
+   UnixFTPEntryParser.java: Support Solaris 
special devices
+   
+   
+   *FTPEntryParser.java: Keep files with 
unparseable dates in list
+   
+   
+   DefaultFTPFileEntryParserFactory.java, 
TFTPRequestPacket.java: Fix String conversions in non-English Locales
+   
+   
+   FTPTimestampParserImpl.java: Fix lenient future 
dates at year boundary
+   
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons net - any ftp servers supporting COMPRESSED_TRANSFER_MODE?

[Oberhuber, Martin]

This must be nonstandard. 

I could not find any reference to "TYPE C" or "TYPE Z"
in the RFCs, or other references linked from
http://en.wikipedia.org/wiki/File_Transfer_Protocol

What products support "TYPE Z" ?

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Thorbjørn Ravn Andersen [mailto:[EMAIL PROTECTED] 
> Sent: Mittwoch, 26. März 2008 11:46
> To: Jakarta Commons Developers List
> Subject: Commons net - any ftp servers supporting 
> COMPRESSED_TRANSFER_MODE?
> 
> The commons net package supports setting the file type to 
> COMPRESSED_TRANSFER_MODE which results in a "TYPE C" being 
> sent to the 
> server.
> 
> I looked around but have been unable to locate any links to a server 
> which actually supports this.  Apparently "TYPE Z" is used in some 
> products to have the datastream gzipped on the fly (which 
> incidentially 
> Commons Net does not know about), and people very frequently suggest 
> "type c:\something" which shows up in my google search 
> shadowing what I 
> really want to know :)
> 
> Is there ANY ftp server out there which supports this feature?
> 
> -- 
>   Thorbjørn
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [NET] 1.5 Leap year processing

[Oberhuber, Martin]

Hi Sebb,

Thanks for your patch, I was not aware that it had not yet been applied.
Thanks also for the new Feb29 testcases.

> The current code does not fix NET-188 for Java 1.3 and 1.4, which NET
> 1.5 is supposed to support.
> 
> The problem is that the 1.3 and 1.4 Java RTLs don't generate a syntax
> error for Feb 29 1970; instead they convert it to Mar 1 1970; the code
> then replaces 1970 with the current (or previous) year. So the
> timestamp appears to parse OK, but is incorrectly parsed.
> 
> The patch I posted recently does work for 1.3+, but does not support
> short dates more than about 10 months old.

Ok, I applied the patch and it's good for the Feb.29 scenario.
But I found a different problem with dates on Jan.1 when
The client computer still has Dec.31 -- which can happen 
Due to time zone differences. The problem existed in the
Old code as well so it's not new with your patch.

Anyways, I commented on Jira so let's follow up discussions there.
   https://issues.apache.org/jira/browse/NET-188

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
> -Original Message-
> From: sebb [mailto:[EMAIL PROTECTED] 
> Sent: Samstag, 15. März 2008 02:34
> To: Jakarta Commons Developers List
> Subject: Re: [NET] 1.5 Leap year processing
> 
> On 14/03/2008, Oberhuber, Martin 
> <[EMAIL PROTECTED]> wrote:
> > Hi Sebb,
> >
> >
> >  > Regex is not available in Java 1.3.
> >  > Also, how does one know where the year is in the string?
> >
> >
> > Code for this already is in Commons Net, using ORO for the Regex.
> >  See UnixFTPEntryParser.java line 105
> 
> OK, did not realise that it used ORO.
> 
> >
> >  > 2.2 If previous year also gives a parse error then give up?
> >
> >
> > Hm... Well, well. The point is that we don't have a chance to
> >  get it right 100%. There's just too much that can go wrong,
> >  for instance:
> >
> >   * Dates are in server local time, but we don't know what
> > "current time" the server thinks it has. Its clock could
> > be off by years in the worst case, making all tries to
> > correctly parse short date impossible.
> >
> >   * We don't know the server time zone for sure
> >
> >   * Time in the client is currently used for substituting
> > current year, but that one could also be wrong.
> 
> Yes.
> 
> >  So - I think I'd like to give it a chance with the current year
> >  and the previous year, and if both fail than create an entry
> >  With a "null" date (1.1.1970 or something like that).
> 
> I think the date should really be null if it cannot be determined.
> 
> >  Also noticed that my algorithm fails in the case where due to
> >  time zone differences, the client computer still has local
> >  year  but server already has +1.
> >
> >  Unfortunately I don't have time right now to code a patch,
> 
> I've already added a patch that works for most cases.
> 
> >  I guess that talking about code would be better than talking
> >  about concepts at this point. That being said, I don't find
> >  Rory's current patch that bad that it justifies further
> >  Holding off the release.
> >
> >  The patch code only strikes when the previous version's code
> >  Would run into a parse exception, and it seems to correctly
> >  Handle the Feb.29 case... So I'm not sure what else is missing
> >  That must go into a 1.5 release...
> >
> 
> 
> >
> >  Cheers,
> >  --
> >  Martin Oberhuber, Senior Member of Technical Staff, Wind River
> >  Target Management Project Lead, DSDP PMC Member
> >  http://www.eclipse.org/dsdp/tm
> >
> >
> >
> > 
> -
> >  To unsubscribe, e-mail: [EMAIL PROTECTED]
> >  For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [NET] 1.5 Leap year processing

[Oberhuber, Martin]

Hi Sebb,

> Regex is not available in Java 1.3.
> Also, how does one know where the year is in the string?

Code for this already is in Commons Net, using ORO for the Regex.
See UnixFTPEntryParser.java line 105

> 2.2 If previous year also gives a parse error then give up?

Hm... Well, well. The point is that we don't have a chance to
get it right 100%. There's just too much that can go wrong,
for instance:

  * Dates are in server local time, but we don't know what
"current time" the server thinks it has. Its clock could
be off by years in the worst case, making all tries to
correctly parse short date impossible.

  * We don't know the server time zone for sure

  * Time in the client is currently used for substituting
current year, but that one could also be wrong.

So - I think I'd like to give it a chance with the current year
and the previous year, and if both fail than create an entry
With a "null" date (1.1.1970 or something like that).

Also noticed that my algorithm fails in the case where due to
time zone differences, the client computer still has local
year  but server already has +1.

Unfortunately I don't have time right now to code a patch, 
I guess that talking about code would be better than talking
about concepts at this point. That being said, I don't find
Rory's current patch that bad that it justifies further 
Holding off the release.
The patch code only strikes when the previous version's code
Would run into a parse exception, and it seems to correctly
Handle the Feb.29 case... So I'm not sure what else is missing
That must go into a 1.5 release...


Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [NET] 1.5 Leap year processing

[Oberhuber, Martin]

What about this:

1.) Use REGEX to parse year into a separate String -> will be empty or 
2.) If year is empty, substitute current year (as seen on client) and parse the 
date
2.1  If a parse error occurs, OR result date is > 3 days in the future, try 
again with previous year
 (in order to account for Jan.1 on the host where client still has Dec.31)
 (allow 3 days in future to be safe in really odd timezone conditions)

My Linux box (RHEL4) currently shows 
"Sep 27 17:28"  for Sep 27, 2007
"Sep  3 2007"   for Sep 3, 2007
"Mar 15 2008"   for Mar 15, 2008

So apparently it uses short dates only for 6 months back.
And doesn't use short dates for future dates even if it's
Just 2 days in the future.

I think that the FTP solution should work properly for the most 
Prevalent system and live with the fact that we don't know if
There are any obscure OS's there which keep using short dates
Even 10 months or more after the date. It's just undefined.

Correct solution will come by using new FTP MDTM / MLST commands.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: sebb [mailto:[EMAIL PROTECTED] 
> Sent: Mittwoch, 12. März 2008 21:37
> To: Commons Developers List
> Subject: [NET] 1.5 Leap year processing
> 
> I think I've found a solution to the leap year processing.
> 
> At present the code tries the short date and then adds the current
> year if the parse fails.
> This does not work on Java 1.4 or earlier because Feb 29 1970 does not
> cause a parse failure - the date is converted to Mar 1 1970.
> 
> One solution seems to be to add the current year to the short date
> initially, so Feb 29 will either parse OK or cause a failure if it's
> not a leap year; the date won't be changed to Mar 1.
> 
> However, I've just realised that it won't work if the current date is
> in Jan or Feb the following year, i.e. 10+ months later.
> 
> Are there any OSes which display short dates more than 10 months after
> the file date?
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] Release Commons Net 1.5

[Oberhuber, Martin]

What about using ftp.microsoft.com for the Windows Tests?
They should be available quite reliably, eh? And it's very
likely that they will keep using a Windows FTP server rather
than switching to UNIX.

Y:\>ftp ftp.microsoft.com
Connected to ftp.microsoft.com.
220 Microsoft FTP Service
User (ftp.microsoft.com:(none)): anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 Anonymous user logged in.
ftp> literal syst
215 Windows_NT
ftp> literal feat
211-FEAT
SIZE
MDTM
211 END

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Rory Winston [mailto:[EMAIL PROTECTED] 
> Sent: Samstag, 08. März 2008 21:39
> To: Jakarta Commons Developers List
> Subject: Re: [VOTE] Release Commons Net 1.5
> 
> The functional tests seem to be broken right now, due to the remote 
> server being unavailable. These don't get run by default 
> anyways, so I 
> think we should just leave this for now, unless someone can suggest a 
> different server.
> 
> Rory
> 
> Oberhuber, Martin wrote:
> > Also, I get unit test failures in
> >FTPClientConfigFunctionalTest.testTimeZoneFunctionality()
> > as well as all FTP Windows tests (looks like ftp.wacom.com 
> > is down -- should a different Windows FTP Server be added?)
> >
> > Cheers,
> > --
> > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> >  
> >  
> >
> >   
> >> -Original Message-
> >> From: Oberhuber, Martin 
> >> Sent: Montag, 03. März 2008 11:50
> >> To: 'Jakarta Commons Developers List'
> >> Subject: RE: [VOTE] Release Commons Net 1.5
> >>
> >> Hi Rory,
> >>
> >> it's great to hear some progress is being made towards a new
> >> commons.net release!!!
> >>
> >> For the 1.5 release candidate, I notice that the binary
> >> JAR now has the examples classes embedded whereas the 1.4 
> >> release did not. Also, some Maven POM stuff is in META-INF.
> >> Is this intentional?
> >>
> >> jar tfv commons-net-1.4.1.jar | awk '{print $8;}' | sort > 
> cn141.txt
> >> jar tfv commons-net-1.5.0*.jar | awk '{print $8;}' | sort 
> > cn150.txt
> >> diff cn150.txt cn141.txt
> >>
> >> 5,39d4
> >> < META-INF/maven/
> >> < META-INF/maven/commons-net/
> >> < META-INF/maven/commons-net/commons-net/
> >> < META-INF/maven/commons-net/commons-net/pom.properties
> >> < META-INF/maven/commons-net/commons-net/pom.xml
> >> < examples/
> >> < examples/IOUtil.class
> >> [...]
> >> < examples/tftp.class
> >> < examples/weatherTelnet.class
> >> 97d61
> >> < org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.class
> >> 179,180d142
> >> < org/apache/commons/net/tftp/TFTPServer$TFTPTransfer.class
> >> < org/apache/commons/net/tftp/TFTPServer.class
> >>
> >> Also, your Source Package includes some odd files which I 
> >> believe should not be part of a release: the "proposal" did
> >> not make it into the binary release, and "src/assembly" has
> >> not been part of 1.4.1:
> >>/propsal/ftp2/
> >>/src/assembly/
> >>/src/java/org/apache/commons/net/tftp/
> >>   -! (DIR)
> >>   TFTPClient-1.4.1-fix.diff
> >>   TFTPClient.java.orig
> >>   TFTPClient.java.rej
> >>   
> >>
> >> The other thing I'd REALLY consider important especially for a
> >> 1.5.x service release, is a list of changes that were made. 
> >> Is such a changelog available anywhere?
> >>
> >> I tried making a source diff, but it throws out ALL files as
> >> different since the copyright headers changed. I think that 
> >> the change in copyright terms might also be worth mentioning
> >> in the change log. More changes were indicated due to RCS
> >> Version tags like  * @version $Id: .*$
> >> or * @version $Revision: .*$
> >>
> >> That being said, I noticed that the following file(s) do *NOT*
> >> carry the new license header in 1.5:
> >>TFTPClient.java
> >> and others e.g. TimeTCPClientTest.java did even carry an
> >> Apache 1.1 license in version 1.4, or no license at all
> >>

RE: [NET] fixing short date parsing problems (was: [VOTE] Release Commons Net 1.5)

[Oberhuber, Martin]

Hi all,

regarding FTP parser date +-6 month problem:

Having a look at
http://www.ietf.org/rfc/rfc3659.txt?number=3659 section 3
it seems that there is a standardization effort in place
to finally get time values right for FTP (proposed standard
"MDTM" command. So this is what we'll want to have in the
future to get 100% correct dates. And this is what clients
could potentially use if a server supports it and the 
normal ftp parser returns a "null" date due to parsing 
problems.

Check availability of this feature on the server with:

ftp> literal syst
215 UNIX Type: L8
ftp> literal feat
211-Features:
 EPRT
 EPSV
 MDTM
 PASV
 REST STREAM
 SIZE
 TVFS
211 End
ftp>

Also, there will be MLST and MLSD for machine listing to
get rid of the problems with LIST / DIR commands (see 
section 7 of RFC3659).

That being said, my point is that if a server doesn't support
the MDTM command and the LS output of "dir" is ambiguous, 
there is not much point in guessing and doing it one way or
the other. I really don't care much about whether dates upto
6 months in the future are returned as future or back, though
I have a slight preference for not dealing with future dates
too much since they are a corner case. One day in the future
is fine since it can happen due to time zone differences, but
not more. Who would consciously create a file in the future?

If in doubt, the MDTM command is the way to go for disambiguating.
And the FTPClient should not send the command itself but allow
the client to send it, if client thinks that exact times are
required.

About anything else in the DIR output, the FTP standard says:
http://www.ietf.org/rfc/rfc0959.txt?number=959
LIST: "Since the information on a file may vary widely from system
   to system, this information may be hard to use automatically
   in a program, but may be quite useful to a human user."

So summing up: I'm in favor of only allowing 1-day-in-the-future
dates and rolling back all others; but I really don't care a lot
since the way to go is standardized commands for machine processing.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Rory Winston [mailto:[EMAIL PROTECTED] 
> Sent: Dienstag, 11. März 2008 21:10
> To: Jakarta Commons Developers List
> Subject: Re: [NET] fixing short date parsing problems (was: 
> [VOTE] Release Commons Net 1.5)
> 
> Sebb/Martin
> 
> The lenient future dates flag just allows a window of +1 day in the 
> short timestamp, which if > now(), will not be rolled back by a year. 
> This is to prevent dates slightly in the future being rolled back 
> inappropriately. You keep mentioning the +/- 6 month thing - 
> the problem 
> is that this (like a lot of other FTP stuff) isn't a standard and you 
> can't depend on it. Still, there are a bunch of other flags 
> in there to 
> work around other issues, so maybe another flag might be required for 
> fully comprehensive date handling.
> 
> Say if we have a date d ( 1 day < d <= 6 months) in the future, this 
> flag would control whether d is rolled back (as it would be 
> now) or kept 
> in the current year (which we would need a flag for).
> 
> Is this what is needed to get the remaining tests to pass?
> 
> Rory
> 
> sebb wrote:
> > On 10/03/2008, sebb <[EMAIL PROTECTED]> wrote:
> >   
> >> On 10/03/2008, Rory Winston <[EMAIL PROTECTED]> wrote:
> >>  > Hi Sebb
> >>  >
> >>  >  A couple of things:
> >>  >
> >>  >  1. Which tests are you referring to in your first point below?
> >>
> >>
> >> 
> testFeb29IfLeapYear(org.apache.commons.net.ftp.parser.FTPTimes
> tampParserImplTest)
> >>  
> testFeb29LeapYear(org.apache.commons.net.ftp.parser.FTPTimesta
> mpParserImplTest)
> >>
> >>  The first one only applies in leap years - it was 
> designed before the
> >>  addition of the server calendar parameter. It could perhaps be
> >>  dropped.
> >>
> >>  I've since fixed the following test, and it also fails, 
> but only on 1.4:
> >>
> >>  
> testFeb29NonLeapYear(org.apache.commons.net.ftp.parser.FTPTime
> stampParserImplTest)
> >>
> >>
> >>  >  2. Does the assumption have anything to do with the 
> lenientFutureDates
> >>  >  flag in FTPTimestampParserImpl?
> >>  >
> >>
> >>
> >> Yes, the *nix future dates thing is tied in with 
> lenientFutureDates.
> >>
> >>  I suspect there may need to be a new flag which enables 
> *nix style +/-
> >>  6 months dates.
> >>
> >>  I don't understand what the lenient flag is about - was 
> it part of an
> >>  attempt to handle *nix dates (in which case it's wrong, as lenient
> >>  allows up to 1 year in arrears), or is it for different OSes?
> >>
> >>  The past and future date tests need extending as well; 
> there should be
> >>  one test where the current date is in the first 6 months 
> of the year,
> >>  and another where it is in the second 6 months of the year (and
> >>  perhaps leap/non-leap years too).
> >>
> >>   

RE: [NET] fixing short date parsing problems (was: [VOTE] Release Commons Net 1.5)

[Oberhuber, Martin]

> Seems to me it would be a lot better if the FTPFile entry was still
> generated, but with a null date.

I agree.

In the past, commons net ftp has always been using strict parsing,
with the result that some files might have been missed. We have
also seen this on Solaris with certain devices which would have
led to "ls" lines that the regular expressions did not understand.

I think that API-wise in 2.0 there should be special "invalid or
unknown" values for each slot of the FTPFile data, in order to 
handle the cases where the parsing fails for any reason.

Setting a "0" date in 1.5 seems to be OK here as well, although
the handling of dates might be sensitive in an environment where
FTP is used as base for virtual file system that performs a "make"
kind of operation (and might thus lead to not re-building parts
of a system). 

It's kind of a philosophical choice, but from a user's perspective
I'd prefer seeing a file with a "null" date rather than not seeing
it at all.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Commons Net 1.5.0: Fixes to consider for backporting

[Oberhuber, Martin]

Hi Rory,
 
I did a quick browse through JIRA issues fixed for commons.net 2.0
but not commons.net 1.5 - and after filtering out those that appear
to be related to the 2.0 branch only, or impossible to fix in 1.5
due to JDK-1.4 or later dependencies, I came up with the following
list.
 
Do you think it makes sense to backport any of these to 1.5.0?
I guess I've sorted the list by order of increasing complexity,
the first few looked like relatively simple low-hanging fruit, but
I might be totally wrong of course... and, if uncertain about 
potential side effects of a fix, I believe I'd rather live with an 
1.5.0 version with fewer features but without regressions...
 
https://issues.apache.org/jira/browse/NET-184
FtpClient.listFiles truncates directory name beginning with a number
 
https://issues.apache.org/jira/browse/NET-59
[net] NullpointerException on FTPClient.disconnect() if an Exception
occured while FTPClient.connect
 
https://issues.apache.org/jira/browse/NET-182
createFileEntryParser needs to null protect from a null 'key' parameter.
 
https://issues.apache.org/jira/browse/NET-170
UnixFTPEntryParser does not handle file owner names with spaces
 
https://issues.apache.org/jira/browse/NET-158
login in FTPClient does not always read the complete server response
 
https://issues.apache.org/jira/browse/NET-148
Relaxed condition in __getReply causes other failures.
 
https://issues.apache.org/jira/browse/NET-177
FTPClient fails to parse valid PASV responses 
 
https://issues.apache.org/jira/browse/NET-145
Deadlock in TelnetInputStream
 
Thanks,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

Commons Net 1.5: Updated Changelog

[Oberhuber, Martin]

Hi Rory,

based on my observations of diff'ing commons.net 1.5.0-candidate
against 1.4.1, I dived into SVN Changelogs and came up with what
I think should be an accurate changelog.

Please consider adding this into xdoc/changes.xml.

I've added JIRA references for the issues fixed, wherever I found
them. I noticed that some of these JIRA references do not have
the "fix version = 1.5.0" associated. I believe that this should
be done in order to support JIRA queries.

Also, I've added the fix for NET-73 here already since I truly
believe this must be added to commons.net 1.5.0.




TelnetInputStream.java: Applied Rob
Hasselbaum's
 alumni.ithaca.edu>
patch for PR 38688 fixing a
TelnetInputStream hang.


TelnetInputStream.java: Fixing another
potential deadlock for 
telnet and FTP (patch courtesy Rob Hasselbaum).


FTP.java: Exposed control connection of
FTP
class via _controlInput_ and
_controlOutput_
protected member variables in response
to PR 38309 reported by
<[EMAIL PROTECTED]>.


TFTPClient.java: Fix bug causing final
packets
to not be sent.


TFTPClient.java: Fix sendFile() (related
to NET-68).


TFTPClient.java: block number
wraparound.


UNIXFTPEntryParser.java: support for
group names with
spaces (patch courtesy D. Kilzer).


DefaultFTPFileEntryParserFactory.java:
Wrap 
NoClassDefFoundError in FTP parser exception
when ORO is not available.


FTPClient.java: Fix closing FTP
ServerSocket after timeout


FTPClientConfig.java: Added an FTP
parser for Netware FTP servers.
Tested on Novell Netware 6.5.


FTPTimestampParserImpl.java: Fix leap
year date parsing bug.


Article.java: Fix minor issues with NNTP
parsing.

 


Thanks,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

NET-73 not included in commons-net 1.5.0 candidate

[Oberhuber, Martin]

Hi Rory,
 
I just found out that the patch for NET-73 has not been included
in the commons net 1.5.0 candidate.
 
We've been using this patch since about a year now and we 
think it's critical for commons.net FTP reliability since it fixes
a potential deadlock. Please consider applying this patch for 
the 1.5.0 candidate.
 
See
http://issues.apache.org/jira/browse/NET-73
https://bugs.eclipse.org/bugs/show_bug.cgi?id=202758#c16
 
 
Thanks,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

RE: [VOTE] Release Commons Net 1.5

[Oberhuber, Martin]

If TFTPServer is for testing only, shouldn't it reside in 
the tests/ source root?

Having a TFTPServer would be cool though, but I have no idea
what level of quality it is.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: sebb [mailto:[EMAIL PROTECTED] 
> Sent: Montag, 03. März 2008 14:29
> To: Jakarta Commons Developers List
> Subject: Re: [VOTE] Release Commons Net 1.5
> 
> >  >  TFTPServer.java
> >  >   SocketTimeoutException  is unknown in J2SE-1.2 or 1.3

> ISTR that the TFTPServer is for testing only, so perhaps one way round
> this would be to exclude it from builds if the JVM does not support
> it.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] Release Commons Net 1.5

[Oberhuber, Martin]

Also,

I see that while commons.net 1.4.1 compiled properly against
J2SE-1.2, there are build errors in 1.5.0 with J2SE-1.2:

TFTPServer.java
  SocketTimeoutException  is unknown in J2SE-1.2 or 1.3

I think it's a severe regression to require J2SE-1.4 or 
later just because of newly added TFTPServer. People have
been sticking with commons.net on Java Micro Editions
especially because of the old J2SE-1.2 compatibility.
This should NOT be broken with 1.5.0.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Oberhuber, Martin 
> Sent: Montag, 03. März 2008 12:57
> To: 'Jakarta Commons Developers List'; 'Rory Winston'
> Subject: RE: [VOTE] Release Commons Net 1.5
> 
> Also, I get unit test failures in
>FTPClientConfigFunctionalTest.testTimeZoneFunctionality()
> as well as all FTP Windows tests (looks like ftp.wacom.com 
> is down -- should a different Windows FTP Server be added?)
> 
> Cheers,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
>  
>  
> 
> > -Original Message-
> > From: Oberhuber, Martin 
> > Sent: Montag, 03. März 2008 11:50
> > To: 'Jakarta Commons Developers List'
> > Subject: RE: [VOTE] Release Commons Net 1.5
> > 
> > Hi Rory,
> > 
> > it's great to hear some progress is being made towards a new
> > commons.net release!!!
> > 
> > For the 1.5 release candidate, I notice that the binary
> > JAR now has the examples classes embedded whereas the 1.4 
> > release did not. Also, some Maven POM stuff is in META-INF.
> > Is this intentional?
> > 
> > jar tfv commons-net-1.4.1.jar | awk '{print $8;}' | sort > cn141.txt
> > jar tfv commons-net-1.5.0*.jar | awk '{print $8;}' | sort > 
> cn150.txt
> > diff cn150.txt cn141.txt
> > 
> > 5,39d4
> > < META-INF/maven/
> > < META-INF/maven/commons-net/
> > < META-INF/maven/commons-net/commons-net/
> > < META-INF/maven/commons-net/commons-net/pom.properties
> > < META-INF/maven/commons-net/commons-net/pom.xml
> > < examples/
> > < examples/IOUtil.class
> > [...]
> > < examples/tftp.class
> > < examples/weatherTelnet.class
> > 97d61
> > < org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.class
> > 179,180d142
> > < org/apache/commons/net/tftp/TFTPServer$TFTPTransfer.class
> > < org/apache/commons/net/tftp/TFTPServer.class
> > 
> > Also, your Source Package includes some odd files which I 
> > believe should not be part of a release: the "proposal" did
> > not make it into the binary release, and "src/assembly" has
> > not been part of 1.4.1:
> >/propsal/ftp2/
> >/src/assembly/
> >/src/java/org/apache/commons/net/tftp/
> >   -! (DIR)
> >   TFTPClient-1.4.1-fix.diff
> >   TFTPClient.java.orig
> >   TFTPClient.java.rej
> >   
> > 
> > The other thing I'd REALLY consider important especially for a
> > 1.5.x service release, is a list of changes that were made. 
> > Is such a changelog available anywhere?
> > 
> > I tried making a source diff, but it throws out ALL files as
> > different since the copyright headers changed. I think that 
> > the change in copyright terms might also be worth mentioning
> > in the change log. More changes were indicated due to RCS
> > Version tags like  * @version $Id: .*$
> > or * @version $Revision: .*$
> > 
> > That being said, I noticed that the following file(s) do *NOT*
> > carry the new license header in 1.5:
> >TFTPClient.java
> > and others e.g. TimeTCPClientTest.java did even carry an
> > Apache 1.1 license in version 1.4, or no license at all
> > (AllTests.java).
> > 
> > Also, is it legally OK to omit the Copyright Years? In 1.4.1,
> > some files were Copyright 2001-2005 while others (especially
> > Telnet) were Copyright 2003-2004 while others (FTPParser) 
> > were Copyright 2004 or Copyright 2005.
> > 
> > In UnixFTPEntryParserTest.java I see that one test case is
> > commented out, is this intentional?
> > 
> > In build.xml you still have this, I think it should not be -dev:
> >
> > 
> > I made some semi-automated editing on the source archives,
> > and came up with following list of files that were changed
> > for 1.5.0 -- perhaps it helps fin

RE: [VOTE] Release Commons Net 1.5

[Oberhuber, Martin]

Also, I get unit test failures in
   FTPClientConfigFunctionalTest.testTimeZoneFunctionality()
as well as all FTP Windows tests (looks like ftp.wacom.com 
is down -- should a different Windows FTP Server be added?)

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Oberhuber, Martin 
> Sent: Montag, 03. März 2008 11:50
> To: 'Jakarta Commons Developers List'
> Subject: RE: [VOTE] Release Commons Net 1.5
> 
> Hi Rory,
> 
> it's great to hear some progress is being made towards a new
> commons.net release!!!
> 
> For the 1.5 release candidate, I notice that the binary
> JAR now has the examples classes embedded whereas the 1.4 
> release did not. Also, some Maven POM stuff is in META-INF.
> Is this intentional?
> 
> jar tfv commons-net-1.4.1.jar | awk '{print $8;}' | sort > cn141.txt
> jar tfv commons-net-1.5.0*.jar | awk '{print $8;}' | sort > cn150.txt
> diff cn150.txt cn141.txt
> 
> 5,39d4
> < META-INF/maven/
> < META-INF/maven/commons-net/
> < META-INF/maven/commons-net/commons-net/
> < META-INF/maven/commons-net/commons-net/pom.properties
> < META-INF/maven/commons-net/commons-net/pom.xml
> < examples/
> < examples/IOUtil.class
> [...]
> < examples/tftp.class
> < examples/weatherTelnet.class
> 97d61
> < org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.class
> 179,180d142
> < org/apache/commons/net/tftp/TFTPServer$TFTPTransfer.class
> < org/apache/commons/net/tftp/TFTPServer.class
> 
> Also, your Source Package includes some odd files which I 
> believe should not be part of a release: the "proposal" did
> not make it into the binary release, and "src/assembly" has
> not been part of 1.4.1:
>/propsal/ftp2/
>/src/assembly/
>/src/java/org/apache/commons/net/tftp/
>   -! (DIR)
>   TFTPClient-1.4.1-fix.diff
>   TFTPClient.java.orig
>   TFTPClient.java.rej
>   
> 
> The other thing I'd REALLY consider important especially for a
> 1.5.x service release, is a list of changes that were made. 
> Is such a changelog available anywhere?
> 
> I tried making a source diff, but it throws out ALL files as
> different since the copyright headers changed. I think that 
> the change in copyright terms might also be worth mentioning
> in the change log. More changes were indicated due to RCS
> Version tags like  * @version $Id: .*$
> or * @version $Revision: .*$
> 
> That being said, I noticed that the following file(s) do *NOT*
> carry the new license header in 1.5:
>TFTPClient.java
> and others e.g. TimeTCPClientTest.java did even carry an
> Apache 1.1 license in version 1.4, or no license at all
> (AllTests.java).
> 
> Also, is it legally OK to omit the Copyright Years? In 1.4.1,
> some files were Copyright 2001-2005 while others (especially
> Telnet) were Copyright 2003-2004 while others (FTPParser) 
> were Copyright 2004 or Copyright 2005.
> 
> In UnixFTPEntryParserTest.java I see that one test case is
> commented out, is this intentional?
> 
> In build.xml you still have this, I think it should not be -dev:
>
> 
> I made some semi-automated editing on the source archives,
> and came up with following list of files that were changed
> for 1.5.0 -- perhaps it helps finding the bugs that were
> resolved for 1.5.0, in order to compile a change list:
> 
> diff -r -b 
> commons-net-1.4.1/src/java/org/apache/commons/net/ftp/FTP.java 
> diff -r -b 
> commons-net-1.4.1/src/java/org/apache/commons/net/ftp/FTPClient.java 
> diff -r -b 
> commons-net-1.4.1/src/java/org/apache/commons/net/ftp/FTPClien
> tConfig.java 
> diff -r -b 
> commons-net-1.4.1/src/java/org/apache/commons/net/ftp/parser/D
> efaultFTPFileEntryParserFactory.java 
> diff -r -b 
> commons-net-1.4.1/src/java/org/apache/commons/net/ftp/parser/F
> TPTimestampParserImpl.java 
> diff -r -b 
> commons-net-1.4.1/src/java/org/apache/commons/net/ftp/parser/N
> TFTPEntryParser.java 
> Only in 
> commons-net-1.5.0-SNAPSHOT-src/src/java/org/apache/commons/net
> /ftp/parser: NetwareFTPEntryParser.java
> diff -r -b 
> commons-net-1.4.1/src/java/org/apache/commons/net/ftp/parser/U
> nixFTPEntryParser.java 
> diff -r -b 
> commons-net-1.4.1/src/java/org/apache/commons/net/nntp/Article.java 
> diff -r -b 
> commons-net-1.4.1/src/java/org/apache/commons/net/telnet/Telne
> tInputStream.java 
> diff -r -b 
> commons-net-1.4.1/src/java/org/apache/commons/net/tftp/TFTPCli
> ent.java 
> Only in 
> commons-net-1.5.0-SNAPSHOT-src/src/java/org/apache/commo

RE: [VOTE] Release Commons Net 1.5

[Oberhuber, Martin]

Hi Rory,

it's great to hear some progress is being made towards a new
commons.net release!!!

For the 1.5 release candidate, I notice that the binary
JAR now has the examples classes embedded whereas the 1.4 
release did not. Also, some Maven POM stuff is in META-INF.
Is this intentional?

jar tfv commons-net-1.4.1.jar | awk '{print $8;}' | sort > cn141.txt
jar tfv commons-net-1.5.0*.jar | awk '{print $8;}' | sort > cn150.txt
diff cn150.txt cn141.txt

5,39d4
< META-INF/maven/
< META-INF/maven/commons-net/
< META-INF/maven/commons-net/commons-net/
< META-INF/maven/commons-net/commons-net/pom.properties
< META-INF/maven/commons-net/commons-net/pom.xml
< examples/
< examples/IOUtil.class
[...]
< examples/tftp.class
< examples/weatherTelnet.class
97d61
< org/apache/commons/net/ftp/parser/NetwareFTPEntryParser.class
179,180d142
< org/apache/commons/net/tftp/TFTPServer$TFTPTransfer.class
< org/apache/commons/net/tftp/TFTPServer.class

Also, your Source Package includes some odd files which I 
believe should not be part of a release: the "proposal" did
not make it into the binary release, and "src/assembly" has
not been part of 1.4.1:
   /propsal/ftp2/
   /src/assembly/
   /src/java/org/apache/commons/net/tftp/
  -! (DIR)
  TFTPClient-1.4.1-fix.diff
  TFTPClient.java.orig
  TFTPClient.java.rej
  

The other thing I'd REALLY consider important especially for a
1.5.x service release, is a list of changes that were made. 
Is such a changelog available anywhere?

I tried making a source diff, but it throws out ALL files as
different since the copyright headers changed. I think that 
the change in copyright terms might also be worth mentioning
in the change log. More changes were indicated due to RCS
Version tags like  * @version $Id: .*$
or * @version $Revision: .*$

That being said, I noticed that the following file(s) do *NOT*
carry the new license header in 1.5:
   TFTPClient.java
and others e.g. TimeTCPClientTest.java did even carry an
Apache 1.1 license in version 1.4, or no license at all
(AllTests.java).

Also, is it legally OK to omit the Copyright Years? In 1.4.1,
some files were Copyright 2001-2005 while others (especially
Telnet) were Copyright 2003-2004 while others (FTPParser) 
were Copyright 2004 or Copyright 2005.

In UnixFTPEntryParserTest.java I see that one test case is
commented out, is this intentional?

In build.xml you still have this, I think it should not be -dev:
   

I made some semi-automated editing on the source archives,
and came up with following list of files that were changed
for 1.5.0 -- perhaps it helps finding the bugs that were
resolved for 1.5.0, in order to compile a change list:

diff -r -b commons-net-1.4.1/src/java/org/apache/commons/net/ftp/FTP.java 
diff -r -b commons-net-1.4.1/src/java/org/apache/commons/net/ftp/FTPClient.java 
diff -r -b 
commons-net-1.4.1/src/java/org/apache/commons/net/ftp/FTPClientConfig.java 
diff -r -b 
commons-net-1.4.1/src/java/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactory.java
 
diff -r -b 
commons-net-1.4.1/src/java/org/apache/commons/net/ftp/parser/FTPTimestampParserImpl.java
 
diff -r -b 
commons-net-1.4.1/src/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java
 
Only in 
commons-net-1.5.0-SNAPSHOT-src/src/java/org/apache/commons/net/ftp/parser: 
NetwareFTPEntryParser.java
diff -r -b 
commons-net-1.4.1/src/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java
 
diff -r -b commons-net-1.4.1/src/java/org/apache/commons/net/nntp/Article.java 
diff -r -b 
commons-net-1.4.1/src/java/org/apache/commons/net/telnet/TelnetInputStream.java 
diff -r -b 
commons-net-1.4.1/src/java/org/apache/commons/net/tftp/TFTPClient.java 
Only in commons-net-1.5.0-SNAPSHOT-src/src/java/org/apache/commons/net/tftp: 
TFTPServer.java

Only in commons-net-1.4.1/target: test-classes
Only in commons-net-1.5.0-SNAPSHOT-src: xdocs

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Rory Winston [mailto:[EMAIL PROTECTED] 
> Sent: Sonntag, 02. März 2008 22:40
> To: Jakarta Commons Developers List
> Subject: [VOTE] Release Commons Net 1.5
> 
> Hi
> 
> This is a release vote for Commons Net 1.5. This release fixes a few 
> issues with TFTP errors, threading hangs, and a leap year 
> date parsing bug.
> 
> The RC deployment is here:
> http://people.apache.org/~rwinston/commons-net-1.5.0/site/
> 
> Binaries:
> 
> http://people.apache.org/~rwinston/commons-net-1.5.0/commons-n
> et-1.5.0-SNAPSHOT-bin.zip
> 
> Source:
> 
> http://people.apache.org/~rwinston/commons-net-1.5.0/commons-n
> et-1.5.0-SNAPSHOT-src.tar.gz
> 
> Javadocs:
> 
> http://people.apache.org/~rwinston/commons-net-1.5.0/site/apid
> ocs/index.html
> 
> SVN tag:
> 
> http://svn.apache.org/viewvc/commons/proper/net/tags/NET_1_5_0/
> 
> Here's my +1 in advance.
> Cheers
> Rory
> 
> --

RE: Commons Net 1.4.x Service Release?

[Oberhuber, Martin]

Hello Jeffrey,

many thanks for offering help!
Are you a Commons Net committer?

For me it looks like there is two tasks for releasing 
commons net 1.4.2:

(a) Look through JIRA to see if there are any more
fixes outstanding or worth backporting. I'm not
100% sure but it could be that there is still an
issue with the Telnet Stream leading to occasional
reliabiliaty problems with FTP. For reference, see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=219792#c2
https://issues.apache.org/jira/browse/NET-145

(b) Take the current commons net 1.4.x branch, make
sure that all Legal files are correct, automated
testing runs OK and make a release.

It would be awsome to get a truly reliable FTP client
from Commons Net 1.4.2 -- for us, having the patches
NET-3 and NET-73 was very important already, but
having our own patched version is not as good as 
having an officially released version.

Thanks!
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Jeffrey Brekke [mailto:[EMAIL PROTECTED] 
> Sent: Dienstag, 26. Februar 2008 04:11
> To: Jakarta Commons Developers List
> Subject: Re: Commons Net 1.4.x Service Release?
> 
> I am willing to help where I can.
> 
> On Mon, Feb 4, 2008 at 5:21 PM, Rory Winston 
> <[EMAIL PROTECTED]> wrote:
> > Hi Martin
> >
> >  Sorry for the late reply. It's been a busy year for me, 
> and I am having
> >  trouble allocating sufficient time to [net] at the moment 
> to close off
> >  the remaining issues and schedule a release, hence the 
> delay. There seem
> >  to be a trickle of bug reports, but unfortunately not much manpower
> >  available to fix them. I was hoping to have a release out 
> long before
> >  now, but unfortunately this has not been the case. If I 
> can find another
> >  interested party to assist with a release, then we can 
> potentially get a
> >  1.4.x and 2.0 release out shortly.
> >
> >
> >
> >  Cheers
> >  Rory
> >
> >  Oberhuber, Martin wrote:
> >  > Hello Rory,
> >  >
> >  > it's been some time since we've had contact regarding
> >  > a commons net 1.4.x service release.
> >  >
> >  > In fact I have applied the patches mentioned below
> >  > that we needed to our own branch of commons net, and
> >  > deployed them with Eclipse. So yes, these patches are
> >  > tested and known to be good.
> >  >
> >  > Eclipse is now going the next round of release train,
> >  > and I'd be interested to get these fixes into an
> >  > officially released version. It looks like others
> >  > need such a patch version too:
> >  >
> >  > [ 
> https://issues.apache.org/jira/browse/NET-68?page=com.atlassia
> n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCo
> mmentId=12559761#action_12559761 ]
> >  >
> >  > Is there a chance to get a commons net 1.4.x release
> >  > any time soon?
> >  >
> >  > Thanks,
> >  > --
> >  > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> >  > Target Management Project Lead, DSDP PMC Member
> >  > http://www.eclipse.org/dsdp/tm
> >  >
> >  >
> >  >
> >  >
> >  >> -Original Message-
> >  >> From: Rory Winston [mailto:[EMAIL PROTECTED]
> >  >> Sent: Monday, September 17, 2007 11:13 PM
> >  >> To: Jakarta Commons Developers List
> >  >> Subject: Re: Commons Net 1.4.x Service Release?
> >  >>
> >  >> Hi Martin (and anyone else who may have commented on this topic)
> >  >>
> >  >> I have been working on and off (not so much recently 
> due to lack of
> >  >> time) on a release for commons-net. I was planning to make
> >  >> a 2.0 release and not specifically release from the 1.4
> >  >> branch, however,
> >  >> it looks like this may now be necessary. I dont have a 
> lot of time
> >  >> at the moment (in fact I had planned an initial 2.0 
> release for a few
> >  >> months ago initially).
> >  >>
> >  >> It may be possible to do a 1.4.x release before 2.0 - this is
> >  >> probably
> >  >> what you will want, as 2.0 will work on a 1.5+ JVM only.
> >  >> Before we look at
> >  >> this however, are you sure that these bug fixes you list
> >  >> below fix the
> >  >> errors you are seeing? Have you verified with a suitable
> &g

FW: Support for OSGi

[Oberhuber, Martin]

FYI:


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas Watson
Sent: Dienstag, 05. Februar 2008 19:52
To: Orbit Developer discussion
Subject: Re: [orbit-dev] FW: Support for OSGi



The thread at
http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00627.html has
surfaced an issue in the OSGi specification which I have surfaced to
OSGi. I opened an Equinox bug to track this discussion. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=217724

In short, I think the specification needs to be changed such that
substitutable exports (the practice of exporting and importing the same
package) does not have adverse effects on require-bundle clients.

Tom

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart
McCulloch
Sent: Freitag, 01. Februar 2008 17:56
To: [EMAIL PROTECTED]
Cc: Commons Developers List; Orbit Developer discussion
Subject: Re: Support for OSGi

> > http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00627.html
> >
> > 1.) Looks like we Eclipse folk will need to continue writing
> > our own OSGi Manifests for some time since the
> > "Require-Bundle" vs. "Import-Package" patterns do not
> > mix too well.

True - of course, if you have several bundles exporting the same
package(s)
but not importing them, then while this means Require-Bundle will be
more
predictable, it also means that you're more likely to see class cast
problems
when you mix 'traditional' OSGi bundles with Eclipse plug-ins.

BTW, here's an example why Require-Bundle is so inflexible, from
Spring-DM:

  
  Spring-DM uses the commons-logging API, but not the implementation
  because it doesn't work well with OSGi classloading (see the
Spring-DM
  FAQ for more detail). People usually use Pax-Logging or other
adapters,
  which is possible because Spring-DM gets the API using
Import-Package.

  Recently a developer using Spring-DM and Eclipse RCP reported a
logging
  problem (he saw the usual exception when using the commons-logging
  implementation) so we suggested he switched to another adapter.

  Unfortunately he was also using the commons-discovery bundle (I think
  from Orbit?) which has a Require-Bundle for commons-logging. This
hard
  dependency meant he couldn't substitute another logging bundle, while
  he could have done if Import-Package was used.

  In the end he re-bundled commons-discovery to use Import-Package
  which fixed the problem, and he now has Spring-DM working with RCP.
  

Given that commons bundles will be used by the wider community then IMHO
they should use the Import-Package approach - hopefully plug-in
developers
will start using it over Require-Bundle (at least for commons packages).

It would have been good to meet everyone's needs but from the link you
> posted and what Peter and Stuart have said in this thread then that
> doesn't seem possible and from my limited perspective it seems clear
> that we (in Commons) should follow whats considerd good OSGi practice
> rather than those of eclipse.
>
> Niall
>
> > 2.) Whenever somebody converts an auto-generated OSGi Manifest
> > into a manually maintained one, it's worth thinking about
> > a) What packages are really API and thus worth being
> >exported, versus what packages are considered internal
> >hidden implementation;


Actually with Bnd, you tell it which packages to export and which to
keep
private - it's just that most commons projects will start by exporting
all
packages, then over time mark some as private. Some commons jars
may also need Bundle-Activators to manage life-cycle issues, such as
background threads, etc. under OSGi.

You can read more about Bnd here:  http://aqute.biz/Code/Bnd

> b) What packages are expected to be potentially split
> >across multiple bundles, or would always reside inside
> >the same bundle.


Again, while Bnd allows split-packages (with a warning) they are usually
not recommended from a 'traditional' OSGi perspective as they quickly
turn into a management nightmare.

FYI, SLF4J used to use split packages, but they refactored their jars to
avoid them, and it solved a lot of issues.

Cheers, Stuart
___
orbit-dev mailing list
[EMAIL PROTECTED]
https://dev.eclipse.org/mailman/listinfo/orbit-dev

RE: Support for OSGi

[Oberhuber, Martin]

Hello Niall / Stuart,

thanks for your answers. It looks like the usage patterns
of OSGi in the Apache and Eclipse communities are just 
a bit different: Apache focuses on packages whereas Eclipse
focuses on Bundle granularity for Re-use.

That's why we don't explicitly import all exported packages
at Eclipse -- we're using Require-Bundle instead of 
Import-Package throughout our system, mostly due to the way
Eclipse Plugins have been workign in the past. For details,
see also 

http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00627.html

What does that mean in practice?

1.) Looks like we Eclipse folk will need to continue writing
our own OSGi Manifests for some time since the 
"Require-Bundle" vs. "Import-Package" patterns do not
mix too well.

2.) Whenever somebody converts an auto-generated OSGi Manifest 
into a manually maintained one, it's worth thinking about
a) What packages are really API and thus worth being 
   exported, versus what packages are considered internal
   hidden implementation;
b) What packages are expected to be potentially split
   across multiple bundles, or would always reside inside
   the same bundle.

Or am I missing something?

Thanks,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf 
> Of Stuart McCulloch
> Sent: Donnerstag, 31. Jänner 2008 16:53
> To: [EMAIL PROTECTED]
> Cc: Jakarta Commons Developers List; Orbit Developer discussion
> Subject: Re: Support for OSGi
> 
> On 31/01/2008, Oberhuber, Martin 
> <[EMAIL PROTECTED]> wrote:
> >
> > Hello Niall,
> >
> > it would be interesting for Eclipse consumers as
> > well to get Apache bundles with Meta-info already
> > applied.
> >
> > Currently, the Meta-info is mostly added manually
> > as part of the Eclipse Orbit project.
> >
> > I have had a brief look at your auto-generated
> > MANIFEST for commons net, and found a few issues:
> >
> > 
> http://people.apache.org/~niallp/commons-osgi/commons-net-1.5.
> 0-SNAPSHOT
> > -MANIFEST.MF
> >
> > 1. Import-Package: examples;version="1.5.0.SNAPSHOT"
> >this is just wrong. The commons net deliverable
> >jar should not import examples.
> 
> 
> I assume there's an examples package somewhere (or something 
> pulls in the
> examples package)
> You can explicitly ask Bnd to remove/ignore this import by 
> using !examples
> in the Import-Package
> if you know that you won't actually need it during runtime (ie. it's
> dead/unused code)
> 
> eg:   !examples,*
> 
> 2. Import-Package: org.apache.commons.net.smtp
> >this is also wrong though less destructive.
> >commons.net.smtp is really exported and not imported.
> 
> 
> Actually this is correct - it's good practice to import your 
> exports as it
> ensures a consistent class
> space and avoids problems when upgrading bundles. Otherwise 
> you *will* run
> into casting issues.
> 
> 3. Export-Package:
> > 
> org.apache.commons.net.smtp;uses:="org.apache.commons.net.io,o
> rg.apache.
> > commons.net"
> >It's useless to add a "uses" directive for
> >packages that are in the same bundle. At
> >Eclipse-Orbit, we've found problems with "uses"
> >and decided to no longer use it.
> 
> 
> As Peter says, he's recently updated Bnd to give users more 
> control over
> "uses" and improved
> the default generation. BTW, there is a good reason for the 
> "uses" clause as
> explained by Glyn:
> 
> 
> http://underlap.blogspot.com/2007/10/osgi-type-safety-and-uses
> -directive.html
> 
> I haven't seen any problem with "uses" on Felix, but I guess 
> Equinox could
> always add an option
> to ignore it - as there are likely to be other bundles out 
> there that have
> "uses" in their manifest.
> 
> I guess that these should perhaps really be bug
> > reports against the Bnd utility which autogenerated
> > the Manifest; Tool: Bnd-0.0.227.
> 
> 
> The elimination of "uses" is really a new feature, and the imports of
> exports is not a bug - the
> only bug (as such) is the appearance of the "examples" 
> package, but I'd need
> to see the final
> jar to understand why Bnd detected it (ie. it may be a 
> justified import
> based on the content)
> 
> But for me, it also shows that in the current stage
> > it looks like the OSG

RE: Support for OSGi

[Oberhuber, Martin]

Hello Niall,

it would be interesting for Eclipse consumers as
well to get Apache bundles with Meta-info already
applied.

Currently, the Meta-info is mostly added manually
as part of the Eclipse Orbit project.

I have had a brief look at your auto-generated
MANIFEST for commons net, and found a few issues:
 
http://people.apache.org/~niallp/commons-osgi/commons-net-1.5.0-SNAPSHOT
-MANIFEST.MF

1. Import-Package: examples;version="1.5.0.SNAPSHOT"
   this is just wrong. The commons net deliverable
   jar should not import examples.

2. Import-Package: org.apache.commons.net.smtp
   this is also wrong though less destructive.
   commons.net.smtp is really exported and not imported.

3. Export-Package:
org.apache.commons.net.smtp;uses:="org.apache.commons.net.io,org.apache.
commons.net"
   It's useless to add a "uses" directive for
   packages that are in the same bundle. At
   Eclipse-Orbit, we've found problems with "uses"
   and decided to no longer use it.

I guess that these should perhaps really be bug
reports against the Bnd utility which autogenerated
the Manifest; Tool: Bnd-0.0.227. 

But for me, it also shows that in the current stage
it looks like the OSGi manifest still needs to be
written by hand and not auto-generated.

Anyways, if there is a plan to make a downloadable
release of any commons packages with OSGi info 
added, I'd like to know.

Thanks,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Niall Pemberton [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, January 29, 2008 11:30 PM
> To: Commons Developers List
> Cc: [EMAIL PROTECTED]
> Subject: Re: Support for OSGi
> 
> I have created a JIRA ticket for the changes to the commons-parent pom
> to add the bundle plugin:
>   https://issues.apache.org/jira/browse/COMMONSSITE-23
> 
> I have also tested out the plugin by generating the jars/manifest for
> all but three components:
>   http://people.apache.org/~niallp/commons-osgi/
> 
> I'll leave the ticket open for a few days - but unless there are
> objections/issues raised I plan to apply the changes to
> commons-parent.
> 
> Niall
> 
> On Dec 19, 2007 2:38 PM, Carsten Ziegeler 
> <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > the products of commons are highly used throughout many projects.
> >
> > It would be great, if the projects here at Apche Commons could help
> > those projects that are using OSGi.
> >
> > OSGi is based around the concept of a bundle - a bundle is 
> a jar file
> > with additional meta data like the packages it exports and a list of
> > external packages it is using (please forgive me if I'm 
> simplifying here
> > too much).
> >
> > As many projects are using artifacts from Apache Commons, 
> they need the
> > specific jars as bundles. This is most often done by 
> creating so called
> > wrapper bundles: these are jars that have the same contents as the
> > original library with the addition of the required meta data.
> > You can find several examples here:
> >
> > http://svn.apache.org/repos/asf/felix/trunk/commons/
> >
> > Now, it would be great, if the projects here at Apache Commons would
> > already provide artifacs that can be directly used in an 
> OSGi environment.
> >
> > All that has to be done is adding some entries to the 
> manifest. This is
> > usually a list of imported packages, a list of exported packages, a
> > symbolic name for the bundle and a version. (There are some more but
> > these are the most important ones).
> >
> > Adding these entries can be done by hand (not recommended) 
> or with tools
> > automatically. For example the Apache Felix maven 
> bundleplugin requires
> > just some lines of configuration and that's it.
> >
> > It would be great if some of the projects here could add 
> these meta data
> > as part of their next release. This will make the life of 
> all projects
> > using OSGi much much easier.
> >
> > So if you're interested in helping us, just let us know. We would be
> > happy to make the required changes to the poms or whatever 
> needs to be
> > done. I cc'ed the Felix dev list as some Felix developers 
> might not be
> > subscribed to the commons dev list, so please keep them 
> cross posted.
> >
> > Thanks
> > Carsten
> > --
> > Carsten Ziegeler
> > [EMAIL PROTECTED]
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Net 1.4.x Service Release?

[Oberhuber, Martin]

Hello Rory,

it's been some time since we've had contact regarding 
a commons net 1.4.x service release.

In fact I have applied the patches mentioned below
that we needed to our own branch of commons net, and
deployed them with Eclipse. So yes, these patches are
tested and known to be good.

Eclipse is now going the next round of release train,
and I'd be interested to get these fixes into an 
officially released version. It looks like others
need such a patch version too:

[ 
https://issues.apache.org/jira/browse/NET-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559761#action_12559761
 ] 

Is there a chance to get a commons net 1.4.x release
any time soon?

Thanks,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -Original Message-
> From: Rory Winston [mailto:[EMAIL PROTECTED] 
> Sent: Monday, September 17, 2007 11:13 PM
> To: Jakarta Commons Developers List
> Subject: Re: Commons Net 1.4.x Service Release?
> 
> Hi Martin (and anyone else who may have commented on this topic)
> 
> I have been working on and off (not so much recently due to lack of 
> time) on a release for commons-net. I was planning to make
> a 2.0 release and not specifically release from the 1.4 
> branch, however, 
> it looks like this may now be necessary. I dont have a lot of time
> at the moment (in fact I had planned an initial 2.0 release for a few 
> months ago initially).
> 
> It may be possible to do a 1.4.x release before 2.0 - this is 
> probably 
> what you will want, as 2.0 will work on a 1.5+ JVM only. 
> Before we look at
> this however, are you sure that these bug fixes you list 
> below fix the 
> errors you are seeing? Have you verified with a suitable 
> source build or 
> nightly?
> 
> Cheers
> Rory
> 
> 
> Oberhuber, Martin wrote:
> > Dear Commons Community,
> >
> > For our Eclipse project DSDP-TM (for an URL, see
> > my signature below), we're picking up Commons Net 
> > 1.4.1 in order to provide remote FTP access. This 
> > is being used in a number of places, including 
> > transparent management of remote web servers.
> >
> > We've recently come across a bug where the FTP
> > connection deadlocks, approximately once out
> > of 20 uploads:
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=202758 
> >
> > We've been able to track this down to two known
> > bugs in Commons Net, which have been fixed about
> > a year ago:
> > https://issues.apache.org/jira/browse/NET-3
> > https://issues.apache.org/jira/browse/NET-73
> >
> > Without these fixes, our tool is pretty useless
> > for FTP, and we cannot see a workaround for the
> > issue. So we really really need the fixes! But 
> > just picking up the patches is not easily possible
> > for us, due to IP cleanliness reasons we'd much
> > prefer a real service release of Commons Net.
> >
> > Looking at the Release Notes embedded in the recent
> > nightlies (Commons Net 1.5-Snapshot), it looks like
> > an 1.4.x service release had been planned at some
> > point but never actually done.
> >
> > Would it be possible to have a Commons Net 1.4.2
> > Service Release? Or what else are the release 
> > plans for Commons Net?
> >
> > Thanks a lot for any insight!
> >
> > Cheers,
> > --
> > Martin Oberhuber
> > Wind River Systems, Inc.
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> >   
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Net 1.4.x Service Release?

[Oberhuber, Martin]

Hello Rory,

thanks for the pointer. Looks like the biggest changes
in commons net 2.0 are
 - Require Java 1.5
 - Use java.util.regex instead of ORO
 - Use JDK SocketFactory
 - Use Maven2 for building
 - Support FTPS

These are interesting, but unfortunately we cannot require
Java 1.5 for our current release cycle. I also think that
even in the future, avoiding java.util.regex and Generics
will be interesting, because there are even modern embedded
JVMs which do not have these - but commons net FTP and 
telnet may be interesting even on a small PDA or Java enabled
cell phone.

I'd thus appreciate if there could be a commons net
1.4.2 or 1.5 service release.

Thanks!
--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm 

> -Original Message-
> From: Rory Winston [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, September 19, 2007 11:36 PM
> To: Jakarta Commons Developers List
> Subject: Re: Commons Net 1.4.x Service Release?
> 
> Hi Martin
> 
> Just the changes for now in svn:
> 
> http://svn.apache.org/viewvc/commons/proper/net/branches/NET_2
> _0/src/site/xdoc/changes.xml?revision=560660&view=markup
> 
> Cheers
> Rory

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Net 1.4.x Service Release?

[Oberhuber, Martin]

PS is there any document that explains the new features in 
Commons Net 2.0 ?

Thanks
martin 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Net 1.4.x Service Release?

[Oberhuber, Martin]

Hello Rory, 

Thanks very much for offering help with a Commons Net 1.4.x release! 
We've been in contact with the original submitter of these fixes,
and he's been using these successfully forr over a year now.

We've also applied the fixes to a local test version, and cannot
see the deadlock any more so we are confident that it fixes the
issue indeed.

Thanks,
Martin

-Original Message-
From: Rory Winston [mailto:[EMAIL PROTECTED] 
Sent: Monday, September 17, 2007 11:13 PM
To: Jakarta Commons Developers List
Subject: Re: Commons Net 1.4.x Service Release?

Hi Martin (and anyone else who may have commented on this topic)

I have been working on and off (not so much recently due to lack of
time) on a release for commons-net. I was planning to make a 2.0 release
and not specifically release from the 1.4 branch, however, it looks like
this may now be necessary. I dont have a lot of time at the moment (in
fact I had planned an initial 2.0 release for a few months ago
initially).

It may be possible to do a 1.4.x release before 2.0 - this is probably
what you will want, as 2.0 will work on a 1.5+ JVM only. Before we look
at this however, are you sure that these bug fixes you list below fix
the errors you are seeing? Have you verified with a suitable source
build or nightly?

Cheers
Rory


Oberhuber, Martin wrote:
> Dear Commons Community,
>
> For our Eclipse project DSDP-TM (for an URL, see my signature below), 
> we're picking up Commons Net
> 1.4.1 in order to provide remote FTP access. This is being used in a 
> number of places, including transparent management of remote web 
> servers.
>
> We've recently come across a bug where the FTP connection deadlocks, 
> approximately once out of 20 uploads:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=202758
>
> We've been able to track this down to two known bugs in Commons Net, 
> which have been fixed about a year ago:
> https://issues.apache.org/jira/browse/NET-3
> https://issues.apache.org/jira/browse/NET-73
>
> Without these fixes, our tool is pretty useless for FTP, and we cannot

> see a workaround for the issue. So we really really need the fixes! 
> But just picking up the patches is not easily possible for us, due to 
> IP cleanliness reasons we'd much prefer a real service release of 
> Commons Net.
>
> Looking at the Release Notes embedded in the recent nightlies (Commons

> Net 1.5-Snapshot), it looks like an 1.4.x service release had been 
> planned at some point but never actually done.
>
> Would it be possible to have a Commons Net 1.4.2 Service Release? Or 
> what else are the release plans for Commons Net?
>
> Thanks a lot for any insight!
>
> Cheers,
> --
> Martin Oberhuber
> Wind River Systems, Inc.
> Target Management Project Lead, DSDP PMC Member 
> http://www.eclipse.org/dsdp/tm
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Commons Net 1.4.x Service Release?

[Oberhuber, Martin]

Dear Commons Community,

For our Eclipse project DSDP-TM (for an URL, see
my signature below), we're picking up Commons Net 
1.4.1 in order to provide remote FTP access. This 
is being used in a number of places, including 
transparent management of remote web servers.

We've recently come across a bug where the FTP
connection deadlocks, approximately once out
of 20 uploads:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=202758 

We've been able to track this down to two known
bugs in Commons Net, which have been fixed about
a year ago:
https://issues.apache.org/jira/browse/NET-3
https://issues.apache.org/jira/browse/NET-73

Without these fixes, our tool is pretty useless
for FTP, and we cannot see a workaround for the
issue. So we really really need the fixes! But 
just picking up the patches is not easily possible
for us, due to IP cleanliness reasons we'd much
prefer a real service release of Commons Net.

Looking at the Release Notes embedded in the recent
nightlies (Commons Net 1.5-Snapshot), it looks like
an 1.4.x service release had been planned at some
point but never actually done.

Would it be possible to have a Commons Net 1.4.2
Service Release? Or what else are the release 
plans for Commons Net?

Thanks a lot for any insight!

Cheers,
--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]