Hi friends,
Iam using apache commons FTPClient (In "commons-net-1.4.1.jar" ). Iam using
it to read files and write a file onto a FTP server.
This class works fine in Windows environment, but its not working on linux (
red hat linux) environment. The following snippet code is for reading a file
o
On Fri, Jun 13, 2008 at 12:27 AM, Matt Benson <[EMAIL PROTECTED]> wrote:
> Update: Luckily pquerna was available on #asfinfra
> and retrieved the production site from www before it
> got synched with the new content. I couldn't get
> JXPATH_1_2 to build the Maven 1 site... though I did
> find an
Update: Luckily pquerna was available on #asfinfra
and retrieved the production site from www before it
got synched with the new content. I couldn't get
JXPATH_1_2 to build the Maven 1 site... though I did
find an email trail where jcarman had had the same
problem before:
Could not find the clas
--- James Carman <[EMAIL PROTECTED]> wrote:
> You're right, imagining the profanity makes this
> message much more
> enjoyable! :)
I don't know about that, but I know that writing it
without felt awfully stifling.
>
> You need to use the "rc" profile when building a
> release candidate.
> The
You're right, imagining the profanity makes this message much more
enjoyable! :)
You need to use the "rc" profile when building a release candidate.
The default profile shouldn't be updating the site. We should have to
turn on a "release" profile or something for that to happen. What
command did
Have I mentioned I HATE Maven? I don't understand how
something that looks innocuous like building an RC can
go out and update the production website, which,
AFAICT, isn't backed up anywhere, so I guess I'll be
trying to regen it from the previous release. Can
anyone tell me simply exactly what c
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The following page has been changed by MattBenson:
http://wiki.apache.org/commons/CreatingReleases
--
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The following page has been changed by MattBenson:
http://wiki.apache.org/commons/CommonsPeople
--
* '''F
On Thu, Jun 12, 2008 at 4:45 PM, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Niall Pemberton <[EMAIL PROTECTED]> wrote:
>
>> On Fri, May 2, 2008 at 6:48 PM, Matt Benson
>> <[EMAIL PROTECTED]> wrote:
>> > Thanks, Seb.
>>
>> I changed the m1 build to use JUnit 3.8.1 and add
>> the new dependency
>>
--- Niall Pemberton <[EMAIL PROTECTED]> wrote:
> On Fri, May 2, 2008 at 6:48 PM, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> > Thanks, Seb.
>
> I changed the m1 build to use JUnit 3.8.1 and add
> the new dependency
> for mockrruner:
Niall, I apologize for having failed to express my
appreciation
Ralph Goers schrieb:
>
>
> James Carman wrote:
>> On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>>> This confuses me. Doesn't the fact that since the code will no
>>> longer run on
>>> a pre-1.5 JDK mean that compatibility is broken, even if not a
>>> single li
Yes, of course! :) But, who does that anymore? ;) I'm kidding of
course. I know that some vendors only support JDK 1.4 currently.
On Thu, Jun 12, 2008 at 11:16 AM, Ralph Goers
<[EMAIL PROTECTED]> wrote:
>
>
> James Carman wrote:
>>
>> On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
>> <[EMAIL PRO
James Carman wrote:
On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
<[EMAIL PROTECTED]> wrote:
This confuses me. Doesn't the fact that since the code will no longer run on
a pre-1.5 JDK mean that compatibility is broken, even if not a single line
of code changes? (Yes - I know that we techni
On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
<[EMAIL PROTECTED]> wrote:
> This confuses me. Doesn't the fact that since the code will no longer run on
> a pre-1.5 JDK mean that compatibility is broken, even if not a single line
> of code changes? (Yes - I know that we technically only release sou
James Carman wrote:
Perhaps we need to come up with a standardized versioning strategy for
Commons projects, then. A simple rule might be that if you're
breaking compatibility, you have to jump major versions and change
your package names (I would argue that whenever we jump version
numbers,
Well the whole commons stack now has support for OSGi and OSGi provides
a mechanism to not export a package so I'd say one should use the
internal package (e.g. org.apache.commons.lang.internal) for all classes
that have to be public but are not part of the public API.
This is better than usin
James Carman schrieb:
> On Thu, Jun 12, 2008 at 8:05 AM, sebb <[EMAIL PROTECTED]> wrote:
>
>
>> Removal of a *public* interface/method/class means that the API is not
>> compatible, as it is not possible to replace the jar without breaking
>> classes that use these items.
>>
>>
>
> I guess
Emmanuel Bourg schrieb:
> sebb a écrit :
>
>> BTW, perhaps Commons should have a similar naming convention for
>> packages that need to contain public methods, but which are only
>> intended to be used in Commons libraries.
>
> Or a big "DO NOT USE THIS CLASS, RESERVED FOR INTERNAL USE" in the
> Ja
Phil Steitz wrote:
Yes, and I would distinguish performance optimization from numerical
accuracy. From my perspective, we can release a ".0" with room for
performance improvement, but at least decent numerics are required.
I agree that decent numerics are required. I'm still rather surpris
[EMAIL PROTECTED] wrote:
> On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
> <[EMAIL PROTECTED]> wrote:
>
>> I would agree that for Lang that *if* the API change breaks
>> compatibility, then a package name change would be appropriate - but
>> I think its a mistake in general to start making deci
sebb a écrit :
BTW, perhaps Commons should have a similar naming convention for
packages that need to contain public methods, but which are only
intended to be used in Commons libraries.
Or a big "DO NOT USE THIS CLASS, RESERVED FOR INTERNAL USE" in the Javadoc ?
Emmanuel Bourg
-
On Thu, Jun 12, 2008 at 8:05 AM, sebb <[EMAIL PROTECTED]> wrote:
> Removal of a *public* interface/method/class means that the API is not
> compatible, as it is not possible to replace the jar without breaking
> classes that use these items.
>
I guess I was thinking of the situation where you'd h
On 12/06/2008, James Carman <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>
> <[EMAIL PROTECTED]> wrote:
>
>
> >> Do you mean that the removal of the enums would mean that we have to
> >> change package names?
> >>
> >> Would class/interface removals necessitate a
On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
<[EMAIL PROTECTED]> wrote:
>> Do you mean that the removal of the enums would mean that we have to
>> change package names?
>>
>> Would class/interface removals necessitate a
>> package name change? I haven't really thought that through.
>
> Perhap
On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
<[EMAIL PROTECTED]> wrote:
> I would agree that for Lang that *if* the API change breaks
> compatibility, then a package name change would be appropriate - but I
> think its a mistake in general to start making decisions along the
> lines JDK 1/5/Ge
On Thu, Jun 12, 2008 at 12:19 PM, James Carman
<[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
> <[EMAIL PROTECTED]> wrote:
>
>>
>> P.S. Perhaps its a moot point in Lang's case since I guess the
>> deprecated enum package has to be removed to move to a minimum of JDK
>
On Thu, Jun 12, 2008 at 2:46 AM, Ralph Goers <[EMAIL PROTECTED]> wrote:
> I haven't been following this list all that long so I'm interested in
> knowing why you want the package names changed. (I apologize in advance to
> those who have already heard this before).
>
Sure. We should probably have
On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
<[EMAIL PROTECTED]> wrote:
>
> P.S. Perhaps its a moot point in Lang's case since I guess the
> deprecated enum package has to be removed to move to a minimum of JDK
> 1.5.
Do you mean that the removal of the enums would mean that we have to
change
On Thu, Jun 12, 2008 at 4:43 AM, James Carman
<[EMAIL PROTECTED]> wrote:
> On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <[EMAIL PROTECTED]> wrote:
>> There is a JIRA item for using generics, and another
>> for varargs. Additionally it'd probably be nice to
>> use generics-level reflection in the o
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-vfs has an issue affecting its community integration.
This issue affects
Hi!
+1 on generics
+99 on package-name change.
+100
The ASM project (org.objectweb.asm) changes their API significantly with
major releases, but do not change the package name. And it causes major
pain. For example, the following libs all require specific versions of ASM:
* hibernate
* dr
I think we should ask the felix people what can be solved with OSGi and
what can not.
Tom
[EMAIL PROTECTED] schrieb:
Tom Schindl schrieb:
I can feel your pain. Thank god I'm using OSGi and can declare my
dependencies explicitly :-)
Yep. Well, it works for those libs that are just internal i
Tom Schindl schrieb:
> I can feel your pain. Thank god I'm using OSGi and can declare my
> dependencies explicitly :-)
Yep. Well, it works for those libs that are just internal implementation
details.
I'm not an OSGi expert, but if any exported class contains a public or
protected method that has
I can feel your pain. Thank god I'm using OSGi and can declare my
dependencies explicitly :-)
I'm also +1 for changing the package name because one can not assume
that everybody is using Felix, Equinox or other OSGi-Envs.
Tom
[EMAIL PROTECTED] schrieb:
James Carman schrieb:
On Wed, Jun 11,
James Carman schrieb:
> On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <[EMAIL PROTECTED]> wrote:
>
>> There is a JIRA item for using generics, and another
>> for varargs. Additionally it'd probably be nice to
>> use generics-level reflection in the oacl.reflect
>> package. Thoughts on [lang] 3.
35 matches
Mail list logo
