Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
From: bugzilla@apache.org
To: commons-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 35898]  -
    [pipeline][PATCH] Fixes for hunk failures in bug #35667
Message-Id: <20050728042310.BDCCFDF@ajax.apache.org>
Date: Thu, 28 Jul 2005 06:23:10 +0200 (CEST)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35898>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35898


------- Additional Comments From skitching@apache.org  2005-07-28 06:23 -------
Hi Kris,

For some reason these patches are still failing to apply. 

I have done the necessary changes manually this time. However what I've applied
is slightly different from your patches as described below.

Generally, @author tags are discouraged in commons components. They are regarded
as not encouraging the community spirit and shared maintenance approach that
commons hopes to occur for its projects. And over a projects' lifetime it is
hoped the code will include many authors, which gets pretty clumsy if they all
get @author lines. Instead, credit is given in the project.xml file (developer,
contributor sections), and for particular cases the release  notes etc. And of
course it's evident in the svn commit info in the usual case of the author
committing their own changes. So while I have left files not touched by this
patch set alone, I have removed @author tags where the patch was trying to
update them. I hope this is ok with you.

It is also not normal practice in commons for the svn commit history to be
present as comments in the code. People who want to see the commit history
should just use "svn log filename". And the current revision# for a file is also
available via "svn info filename" without even needing network access assuming
someone is working with a svn working copy. So where patches are touching such
info I have removed this.

=====
On a separate note, I have noticed that LogStage has this:
    private Log log = LogFactory.getLog(this.getClass());
while most other classes have this:
    private static final Log log = 
      LogFactory.getLog(FtpFileDownloadStage.class);

The latter is more efficient in time and space as it only retrieves the logger
once, rather than once per object. However if this code is ever deployed into a
container's shared classpath then the static version is certainly wrong. Whether
the per-instance version is right or wrong depends upon whether the object
instance could be visible to multiple components (webapps/ejbs/etc).

Just food for thought..

Anyway, pipeline now compiles and the tests all run clean.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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