Author: sgoeschl
Date: Thu Mar 15 04:56:12 2007
New Revision: 518598
URL: http://svn.apache.org/viewvc?view=revrev=518598
Log:
Fixed typo that broke the usage of the watchdog (watchDog vs. watchdog)
Modified:
[
https://issues.apache.org/jira/browse/CLI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated CLI-71:
-
Fix Version/s: 1.1
[cli] A weakness of parser
--
Key: CLI-71
Failed build logs:
/20070317/fileupload.log
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 3/17/07, Torsten Curdt [EMAIL PROTECTED] wrote:
I'd like to bring this well before an actual vote.
At the moment I am still in the middle of documenting and fixing up
JCI for a first 1.0 release. I hope to be able to provide a first RC1
at the end of next week ...latest the week after.
On Fri, 16 Mar 2007 13:18:23 -0700, Elli Albek wrote:
I use DBCP, and in our multithreaded performance test of DAOs we found
that multiple threads are basically blocking on the connection pool class,
either waiting to get a connection or to return a connection. In the test
most threads were
Folks,
Please correct me if I am wrong, but the auto-discovery mechanism in
Commons Logging is believed to be the only major gripe about JCL.
What happened to the idea of releasing a version of JCL that retains the
full API compatibility with JCL 1.0.x and 1.1.x but with the
auto-discovery
On 17.03.2007, at 15:20, Oleg Kalnichevski wrote:
Folks,
Please correct me if I am wrong, but the auto-discovery mechanism in
Commons Logging is believed to be the only major gripe about JCL.
What happened to the idea of releasing a version of JCL that
retains the
full API compatibility
Seems like a bad idea for a Commons component:
* Potential confusion due to version numbers of modules moving
independently etc..
* Its unlikely that releasing one module is significantly easier than
releasing all.
* Its likely that even though after a given quantum of time major
changes are in
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-test has an issue affecting its community
integration.
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-test has an issue affecting its community
integration.
2) Multi-project
JCI uses the maven2 multi-project feature for modularity. Now this
makes it the first multi-project release in commons and question is
how we should handle versioning and voting procedure. In theory it
would be good to be able to have individual releases of the modules.
2) Multi-project
JCI uses the maven2 multi-project feature for modularity. Now this
makes it the first multi-project release in commons and question is
how we should handle versioning and voting procedure. In theory it
would be good to be able to have individual releases of the modules.
Please let me know if you aagree with the following proposal:
I would like to extend Jexl to support comparison operations between
used-defined types.
This will enable Jexl to do comparison operations between user-define data
types that are not a-priori comparable. For example, you will be able
On 3/17/07, Torsten Curdt [EMAIL PROTECTED] wrote:
2) Multi-project
JCI uses the maven2 multi-project feature for modularity. Now this
makes it the first multi-project release in commons and question is
how we should handle versioning and voting procedure. In theory it
would be good to be
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-fmt-test has an issue affecting its community
integration.
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-fmt-test has an issue affecting its community
integration.
Author: bayard
Date: Sat Mar 17 08:57:51 2007
New Revision: 519356
URL: http://svn.apache.org/viewvc?view=revrev=519356
Log:
Add log url in so people can find the right logs
Modified:
jakarta/commons/proper/commons-nightly/trunk/vmbuild.conf
Modified:
[
https://issues.apache.org/jira/browse/IO-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481869
]
Oliver Heger commented on IO-115:
-
The problem seems to be fixed in revision 518770
Henri Yandell wrote:
On 3/16/07, Torsten Curdt [EMAIL PROTECTED] wrote:
snip/
3) Let's remove the commons-configuration-integration and
RESEARCH_CLI_2_ROXSPRING branch. There was no activity within the
past 20 months unless I am mistaken. So I think we can safely say
these tries were
Oops... try it now.
-Matt
--- Henri Yandell [EMAIL PROTECTED] wrote:
That 403s. Can you fix the perms?
Hen
On 3/15/07, Matt Benson [EMAIL PROTECTED]
wrote:
Sorry for the lack of a bracketed subtopic. But
that's my point. ;) I have some code--mostly
extracted from Ant--to check
[jci] javac tests are failing
-
Key: SANDBOX-188
URL: https://issues.apache.org/jira/browse/SANDBOX-188
Project: Commons Sandbox
Issue Type: Bug
Components: JCI
Environment: Windows XP
java
[
https://issues.apache.org/jira/browse/SANDBOX-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski updated SANDBOX-188:
-
Attachment: target.zip
Attached target directory with reports of failing tests.
Oliver Heger wrote:
Henri Yandell wrote:
On 3/16/07, Torsten Curdt [EMAIL PROTECTED] wrote:
snip/
3) Let's remove the commons-configuration-integration and
RESEARCH_CLI_2_ROXSPRING branch. There was no activity within the
past 20 months unless I am mistaken. So I think we can safely
[
https://issues.apache.org/jira/browse/IO-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481882
]
Jochen Wiedmann commented on IO-115:
Checking this in was unintentional. My plan was to discuss the issue before
On 3/17/07, Phil Steitz [EMAIL PROTECTED] wrote:
Failed build logs:
/20070317/fileupload.log
Where can I inspect this log file?
Thanks,
Jochen
--
Emacs 22 will support MacOS and CygWin. It is not yet decided, whether
these will be used to run Emacs or the other way round
On 3/17/07, Jochen Wiedmann [EMAIL PROTECTED] wrote:
On 3/17/07, Phil Steitz [EMAIL PROTECTED] wrote:
Failed build logs:
/20070317/fileupload.log
Where can I inspect this log file?
http://vmbuild.apache.org/~commons/nightly/logs/20070317/fileupload.log
I fixed the mail so it should
On 3/17/07, Henri Yandell [EMAIL PROTECTED] wrote:
On 3/17/07, Jochen Wiedmann [EMAIL PROTECTED] wrote:
On 3/17/07, Phil Steitz [EMAIL PROTECTED] wrote:
Failed build logs:
/20070317/fileupload.log
Where can I inspect this log file?
http://vmbuild.apache.org/~commons/nightly/logs
On 3/17/07, Henri Yandell [EMAIL PROTECTED] wrote:
Probably because the nightly builds aren't deployed to the snapshots
yet. Phil had to expire his key for doing that, and as an empty
passphrase ssh is a bit of an ssh issue, I've avoided turning that
back on.
That seems to be the problem,
can the parent commons-sandbox be released so all sandbox components
can be built by themselves?
it just needs to have the parent version updated to 2
or even better if commons parent is also released to take advantage of
latest changes before releasing sandbox parent.
--
I could give you my
On 3/17/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
can the parent commons-sandbox be released so all sandbox components
can be built by themselves?
it just needs to have the parent version updated to 2
or even better if commons parent is also released to take advantage of
latest changes before
On 16/03/07, Torsten Curdt [EMAIL PROTECTED] wrote:
On 16.03.2007, at 05:28, Henri Yandell wrote:
On 3/15/07, Torsten Curdt [EMAIL PROTECTED] wrote:
IMO we should do a cli 1.0.1 bug release and get then get 2.0 out of
the door ASAP.
Someone needs to have the energy (and comprehension) to
Please open an enhancement request in JIRA [1]. Proposals on the
mailing list tend to get lost unless there is immediate interest /
cycles available. Thanks.
-Rahul
[1] http://issues.apache.org/jira/browse/JEXL
On 3/17/07, Dimitri Papaioannou [EMAIL PROTECTED] wrote:
Please let me know if
Typo in NNTPClient javadoc comment
--
Key: NET-154
URL: https://issues.apache.org/jira/browse/NET-154
Project: Commons Net
Issue Type: Improvement
Reporter: Brian Lewis
Priority:
On Sat, 2007-03-17 at 16:23 +0100, Torsten Curdt wrote:
On 17.03.2007, at 15:20, Oleg Kalnichevski wrote:
Folks,
Please correct me if I am wrong, but the auto-discovery mechanism in
Commons Logging is believed to be the only major gripe about JCL.
What happened to the idea of
Hi!
I had a quick look at the filesystem alteration monitor module -
looks like could be useful component for people outside of JCI.
Yea, in the long term we discussed to replace the VFS's one with this
implementation, though, if it is its own component with an abstract FS
implementation it
35 matches
Mail list logo
