Tim O'Brien [EMAIL PROTECTED] writes:
I know that most posters love Option A, however this makes it very
hard to check out the whole commons in one go. Which is what
e.g. the maven reactor builds would like to have (are they still
used?) or the commons builds, that need the site module.
You have
Tim O'Brien [EMAIL PROTECTED] writes:
Not following this one, this implies that ASF has one trunk. Even
though copies are cheap I wouldn't want to create a copy of the entire
SVN tree for every release.
So, don't do it. Just copy your directory. into the release.
Subversion does not have the
Not very convenient to manage, though. Option B is better IMHO.
I don't understand this argument. One propset/propdel combo for
promotion or demotion is very manageable.
However, as other arguments in this thread have put forward, option A
has other benefits that don't have an alternative,
Noel J. Bergman [EMAIL PROTECTED] writes:
I also prefer the flatter layout:
jakarta/commons/tags/
/branches
/trunk
We don't version Commons as a single component, and I don't know that we
want to force everyone to always take every single component. Someone
Hi Henning,
I replied to this on jakarta general the other day.
A major nit that I have to pick is the growing number of project
building with maven and the inability of _many_ maven plugins like the
changelog, dev or file activity lists to _use_ subversion. This is
many = 4. the 3 you listed,
Brett Porter [EMAIL PROTECTED] writes:
Hi Henning,
Hi Brett,
A major nit that I have to pick is the growing number of project
building with maven and the inability of _many_ maven plugins like the
changelog, dev or file activity lists to _use_ subversion. This is
many = 4. the 3 you listed,
Are these the versions released with 1.0.2? Also I feel uncomfortable
with works on one platform but not on another.
Yes. There is a windows specific bug in that release, so an updated
plugin will be made available for those publishing a site from a windows
machine.
This requires a manual
I think handling different versions of classes/jars at VM level would be a nice
feature, but it would be very hard to implement nd to understand when it comes
to reflection.
Another proposal would be to do it the j2se-way:
When introducing new features to a package (e.g. java.io) don't include
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-chain has an issue affecting its community integration.
This issue
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-id has an issue affecting its community integration.
This issue affects
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-jelly-tags-jsl has an issue affecting its community integration.
This
olegk 2004/12/20 03:39:04
Modified:httpclient/src/java/org/apache/commons/httpclient
ProxyClient.java
Log:
Removed references to deprecated methods
Revision ChangesPath
1.5 +6 -6
In case someone missed the thread on general
here is a re-post as Brett suggested...
Thanks for the positive feedback so far.
BTW: How far is the SVN migration?
cheers
--
Torsten
Torsten Curdt wrote:
Hey, folks!
Over at cocoon we have some code that might be worth
sharing on jakarta commons. So I
olegk 2004/12/20 03:42:30
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java
httpclient/src/test/org/apache/commons/httpclient
TestConnectionPersistence.java
Log:
PR #32333 (Connection not
olegk 2004/12/20 03:47:46
Modified:httpclient/src/java/org/apache/commons/httpclient
DefaultHttpMethodRetryHandler.java
Log:
PR #32558 (DefaultMethodRetryHandler bug)
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke
Revision Changes
olegk 2004/12/20 03:50:55
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpState.java
Log:
PR #32409 (HttpState should have methods for clearing all cookies and
credentials)
Contributed by Oleg Kalnichevski
Reviewed by Michael Becke
olegk 2004/12/20 03:52:53
Modified:httpclient release_notes.txt
Log:
PR #32333
PR #32558
PR #32409
Revision ChangesPath
1.44 +11 -0 jakarta-commons/httpclient/release_notes.txt
Index: release_notes.txt
was offline for a few hours
...you guys are quick :o)
Thanks for granting the karma, Craig.
Although I'd like to commit the
stuff right away it probably makes
sense to wait util the switch to
svn is done. Or what do you guys
reckon?
cheers
--
Torsten
In case someone missed the thread on general
i'd say go for it now :)
-- dims
On Mon, 20 Dec 2004 13:00:41 +0100, Torsten Curdt [EMAIL PROTECTED] wrote:
was offline for a few hours
...you guys are quick :o)
Thanks for granting the karma, Craig.
Although I'd like to commit the
stuff right away it probably makes
sense to wait util
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=26659.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Jakarta Commons Developers List [EMAIL PROTECTED] schrieb am
20.12.04 12:42:26:
In case someone missed the thread on general
here is a re-post as Brett suggested...
Thanks for the positive feedback so far.
BTW: How far is the SVN migration?
cheers
--
Torsten
Torsten Curdt wrote:
So, three issues to know about re: svn:
0. Subclipse: If you use Subclipse - know tha the test repository uses a
self-signed cert, you may need to hit the test repository with svn
command-line and permanently accept the cert from my machine before you
can use subclipse. I was able to checkout
[
http://nagoya.apache.org/jira/browse/JELLY-177?page=comments#action_56890 ]
Denis Robert commented on JELLY-177:
Don't thank me, thank the Freemarker developers, since the technique was lifted
from them.
In JellyServlet, the procedure used to
[
http://nagoya.apache.org/jira/browse/JELLY-177?page=comments#action_56894 ]
Denis Robert commented on JELLY-177:
So as to properly render unto Gaius Julius, here's the reference to the
complete source of the freemarker servlet I used as source:
Henning P. Schmiedehausen wrote:
Checking out the whole trunk is not the norm.
Folks, this is not CVS. You are not bound to a rigid structure as with
CVS. But you _want_ to be able to check out multiple projects side by
side. Because some of the depend on each other (or on the commons-site
Whether you choose Log to be an interface or an abstract class does
not really matter. The point I am trying to convey is that jcl will
not be able to abstract more than one logging API. Although desirable,
abstraction is not technically feasible.
At 12:59 AM 12/20/2004, Matt Sgarlata wrote:
I
Folks,
I took a quick look at the test SVN repository. All looks sane to me. I
checked out HttpClient 3.0 (trunk) and HttpClient 2.0.x
(HTTPCLIENT_2_0_BRANCH) snapshots. They seems identical to the CVS
content of two days ago. As far as I am concerned we should be good to
take the plunge
Cheers,
On Mon, 20 Dec 2004 08:02:14 -0500, Tim O'Brien [EMAIL PROTECTED] wrote:
1. Scheduling: If we go forward with this migration, we need to do this
when everyone is available both so we can migrate successfully and so
that we can have a proper 72 hour vote window. Doing this right before
a
Yes, the intent isn't to leave anyone behind.
I just noticed that infrastructure changes don't have a section in the
guideline proposal: http://jakarta.apache.org/site/proposal.html#decisions/items
From: Henri Yandell
well. Was thinking this qualifies again as a release majority vote.
At
Aren't you assuming that things can be placed in nice orthogonal and
independent boxes?
Let X and Y be logging APIs that JCL attempts to abstract. Let IX be
an interface unique to API X. Let JCL-IX be JCL's mirror of interface
IX. If the end-user sprinkles her code with JCL-IX calls, there are
two
ozeigermann2004/12/20 07:23:56
Modified:transaction/src/java/org/apache/commons/transaction/locking
GenericLockManager.java
Log:
Some fixes around global timeouts
Revision ChangesPath
1.9 +22 -10
martinc 2004/12/20 08:13:42
Modified:fileupload/src/java/org/apache/commons/fileupload
FileUploadBase.java
Log:
Fix typos in exception messages.
Revision ChangesPath
1.15 +3 -3
In my last message, I failed to emphasize the brittleness of the
break into interfaces hypothesis. Even if at a high-level of
abstraction two APIs perform the same task, this does not mean that
they can be abstracted away by a thin facade (or bridge). For example,
all the attempts
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=32782.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
olegk 2004/12/20 11:52:50
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpConnection.java HttpVersion.java
Log:
Javadoc fixes
Contributed by Ernst de Haan ernst.dehaan at nl.wanadoo.com and Oleg
Kalnichevski
Revision Changes
On 18 Dec 2004, at 20:18, Richard Sitze wrote:
[forgive me for changing the subject, I'm trying to take steps to try
to
help us focus on separate issues]
Noel J. Bergman [EMAIL PROTECTED] wrote on 12/17/2004 09:10:34 PM:
Richard Sitze wrote:
As a real example, the axis community uses globalized
I have
Table with these column name and types
INDEX_ID NUMBER,
DOCUMENT_TYPE VARCHAR2(3),
DATE_ENTERED DATE,
SELECT index_id, document_type, date_entered from MyTable;
and database has required data.
public MyBean class {
public long index_ID;
public String
On 18 Dec 2004, at 18:24, Richard Sitze wrote:
Curt Arnold [EMAIL PROTECTED] wrote on 12/16/2004 11:13:25 PM:
On Dec 16, 2004, at 7:56 PM, Richard Sitze wrote:
snip
Some of advantages of this approach: no API change is necessary,
diagnostic messages are still trivial to add and fast to process,
On 18 Dec 2004, at 20:52, Curt Arnold wrote:
On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote:
snip
That a single log request can be rendered for more than one locale
would either require having a localizable object passing through the
logging dispatch system, being able to translate the log
rdonkin 2004/12/20 14:04:53
Modified:betwixt/src/java/org/apache/commons/betwixt/io/read
ReadContext.java
betwixt/src/test/org/apache/commons/betwixt/io/read
TestReadContext.java
Log:
Fix for bug #32743. (Wouldn't you
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=32743.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
On 18 Dec 2004, at 20:52, Curt Arnold wrote:
On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote:
snip
We ARE assuming that maintaining SOME SIGNIFICANT compatibility with
the
existing JCL is of paramount importance. We are NOT trying to
standardize
on some other API within the industry, but
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=32743.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
At 11:03 PM 12/20/2004, robert burrell donkin wrote:
(ceki - can't you keep your troops in line! ;)
I really don't have any troops marching at my orders. Those who are
affiliated with Logging Services do not necessarily listen to me
anyhow, let alone take any orders. They are all independently
On 20 Dec 2004, at 22:21, Ceki Gülcü wrote:
At 11:03 PM 12/20/2004, robert burrell donkin wrote:
(ceki - can't you keep your troops in line! ;)
I really don't have any troops marching at my orders. Those who are
affiliated with Logging Services do not necessarily listen to me
anyhow, let alone
David Graham wrote:
--- Daniel Florey [EMAIL PROTECTED] wrote:
BTW: Another advantage of this approach would be that imports would
indicate
which version of the component is in use. I had a lot of trouble to find
out, which version of jdom was in use by some libraries as this was not
indicated by
Daniel Florey wrote:
I think handling different versions of classes/jars at VM level would be a nice feature, but it would be very hard to implement nd to understand when it comes to reflection.
Does this mean .NET doesn't have reflection? That's such a killer
feature of Java; I can't believe
Robert, we've got some issues to work through and infrastructure wants to wait
until at least next week. Don't delay anything on account of the svn
migration. From what I see, the transition should be seemless - just a few
hours downtime. So, commit away.
Tim
From: robert burrell donkin
.Net does have reflection. Some even say it's somewhat more elegant
than Java... I ain't goin' there :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Matt Sgarlata wrote:
Daniel Florey wrote:
I think handling different versions of
First, you need to alias the column names in the sql to avoid having to
use the horrible underscore in your java method names:
select index_id as indexID, document_type as documentType, date_entered as
dateEntered from MyTable
DBUtils 1.0 didn't contain very intelligent column to bean property
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=32785.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Matt Sgarlata wrote:
Does this mean .NET doesn't have reflection? That's such a killer
feature of Java; I can't believe they wouldn't have ported it to .NET.
Any .NET developers out there that can tell us how .NET deals with
reflection when you have multiple versions of the same class?
Since
52 matches
Mail list logo
