+1
Daniel
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Im Auftrag von Oliver Zeigermann
Gesendet: Samstag, 20. November 2004 02:28
An: Jakarta Commons Developers List
Betreff: [transaction][VOTE] Release 1.0-RC1
Dear community,
I would like to
dflorey 2004/11/21 01:50:18
Modified:transaction project.xml
Log:
Removed organization name
Revision ChangesPath
1.3 +1 -1 jakarta-commons/transaction/project.xml
Index: project.xml
===
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-latka 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-jelly-tags-ant has an issue affecting its community integration.
This
I prepared a bundle for dumbster on codehaus. It will be synchronize with
ibiblio in few hours.
Emmanuel
- Original Message -
From: Henri Yandell [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Friday, November 19, 2004 5:26 AM
Subject: Re: [VOTE] Promote
Hey, great, this is almost readable now ;)
Oliver
On 21 Nov 2004 07:52:27 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
masonjm 2004/11/20 23:52:27
Modified:transaction/xdocs/locks tutorial.xml
Log:
Minor grammar and spelling fixes.
Revision ChangesPath
1.3
To whom it may satisfy...
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-latka *no longer* has an issue.
The current state of this project is
rdonkin 2004/11/21 13:08:32
Modified:betwixt/src/java/org/apache/commons/betwixt/strategy
NamespacePrefixMapper.java
Log:
Fixed javadocs typo
Revision ChangesPath
1.3 +2 -2
rdonkin 2004/11/21 13:26:27
Modified:commons-build commons-site.jsl project.xml
Log:
Removed apachecon references.
Revision ChangesPath
1.14 +1 -1 jakarta-commons/commons-build/commons-site.jsl
Index: commons-site.jsl
rdonkin 2004/11/21 13:28:14
Modified:betwixt/xdocs faq.xml
Log:
Added note on conversions to the FAQ
Revision ChangesPath
1.11 +16 -1 jakarta-commons/betwixt/xdocs/faq.xml
Index: faq.xml
===
I believe Chain is now sufficiently complete and stable to warrant an
official 1.0 release. There are no outstanding bug reports, and the
component is already in use in a number of projects.
The plan is to release HEAD as Commons Chain 1.0 on completion of a
successful vote. I will be the
The Jakarta Commons team is pleased to announce the first beta release
of HttpClient 3.0. Starting with this release the 3.0 API is frozen. We
will now focus on creating additional documentation and test cases. All
current HttpClient 2.0 users are strongly encouraged to migrate to 3.0.
As
I've uploaded JDiff and Clirr reports comparing the current HEAD with
Commons IO 1.0. They're available here:
http://cvs.apache.org/~martinc/io/
If these look OK (they do to me), and people are happy with the current
state of the code, I'd like to go ahead and start the release process for
IO
To whom it may satisfy...
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-latka *no longer* has an issue.
The current state of this project is
In order to write the normalize() method properly, I realised that we have
to deal with filename prefixes properly. The point being that you can't ..
up into a filename prefix.
Here's the javadoc for the method I'm writing. Does this cover the cases?
/**
* Returns the length of the
Objection! ;-)
I believe that a number of the FilenameUtils methods still need work
In particular the normalize(), catPath() and resolveFile() methods. Also the
path methods need clarifying and reworking now that I've discovered a need
to identify the prefix part of the filename (other thread).
On Mon, 22 Nov 2004 01:03:28 -, Stephen Colebourne
[EMAIL PROTECTED] wrote:
In order to write the normalize() method properly, I realised that we have
to deal with filename prefixes properly. The point being that you can't ..
up into a filename prefix.
Here's the javadoc for the method
scolebourne2004/11/21 17:11:56
Modified:io/src/java/org/apache/commons/io FilenameUtils.java
Log:
Add commented out implementations of prefix handling, Javadoc
Revision ChangesPath
1.26 +218 -17
jakarta-commons/io/src/java/org/apache/commons/io/FilenameUtils.java
Hi,
I don't have any comment on the implementation, but I'm not wild on the
use of the name filename prefix.
Perhaps file origin (as in a graph origin, being the point that
coordinates are relative to)? Or file source?
Regards,
Simon
Basically it looks like we'll need:
getPrefix() - C:\
getPath() - dev\project
getFullPath() - C:\dev\project
getName() - file.txt
getExtension() - txt
(input C:\dev\project\file.txt)
Normalize/catPath can then use the other methods to stitch together a
result.
Naming:
catPath() should be
Prefix is the name used internally in the JDK File/FileSystem class. I'm not
completely averse to alternatives, but I do quite like the 'prefix'. Mainly,
I think thats because we are dealing with filenames here not files.
Stephen
- Original Message -
From: Simon Kitching [EMAIL
On Mon, 22 Nov 2004 01:17:40 -, Stephen Colebourne
[EMAIL PROTECTED] wrote:
Basically it looks like we'll need:
getPrefix() - C:\
getPath() - dev\project
getFullPath() - C:\dev\project
getName() - file.txt
getExtension() - txt
(input C:\dev\project\file.txt)
Perhaps one more:
+1
If the beanutils and digester dependencies are updated, it looks like
commons-collections can be removed as a dependency from the project.xml
file.
David
--- Martin Cooper [EMAIL PROTECTED] wrote:
I believe Chain is now sufficiently complete and stable to warrant an
official 1.0 release.
martinc 2004/11/21 17:49:56
Modified:commons-build project.xml
commons-build/xdocs volunteering.xml
Log:
Nagoya is going away, so use the logical names instead.
Revision ChangesPath
1.35 +2 -2 jakarta-commons/commons-build/project.xml
Index:
martinc 2004/11/21 17:55:12
Modified:chainproject.xml
Log:
Update BeanUtils and Digester versions; remove Collections dependency;
update version number to 1.0-dev in anticipation of a 1.0 release soon.
Revision ChangesPath
1.10 +3 -8
martinc 2004/11/21 17:59:50
Modified:chainbuild.xml
Log:
Regenerate Ant build file to pick up changes to project.xml.
Revision ChangesPath
1.9 +164 -381 jakarta-commons/chain/build.xml
Index: build.xml
The Resources project has been in the sandbox for quite some time, and is
essentially complete and almost ready for a release. Several projects are
using it already, and others are ready to pick it up once it is released.
Therefore I propose that we promote Resources out of the sandbox and into
---
[X] +1 I support this proposal and am willing to help
[ ] +0 I support this proposal but am unable to help
[ ] -0 I do not support this proposal
[ ] -1 I do not support this proposal, and here are my reasons
+1.
On Sun, 21 Nov 2004 18:20:33 -0800 (PST), Martin Cooper
[EMAIL PROTECTED] wrote:
The Resources project has been in the sandbox for quite some time, and is
essentially complete and almost ready for a release. Several projects are
using it already, and others are ready to pick it up once it
dion2004/11/21 19:05:08
Modified:jelly/xdocs changes.xml
Log:
[maven-scm-plugin] prepare release 1.0-RC1
Revision ChangesPath
1.23 +1 -1 jakarta-commons/jelly/xdocs/changes.xml
Index: changes.xml
dion2004/11/21 19:12:56
Modified:jellyproject.xml
Log:
Put back entity that scm:prepare-release removed
Revision ChangesPath
1.154 +99 -61jakarta-commons/jelly/project.xml
Index: project.xml
Stephen,
What happens to getExtension() when there is no . character? Also,
what is there are multiple ., are you thinking name.substring(
name.lastIndexOf( . ) + 1 )?
What does getPrefix() return on Unix? Nothing?
Tim
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL
dion2004/11/21 19:26:01
Modified:jellyproject.xml
Log:
Fix up entity stuffup via scm:prep
Revision ChangesPath
1.155 +21 -53jakarta-commons/jelly/project.xml
Index: project.xml
===
dion2004/11/21 19:27:47
Modified:jellyproject.xml
Log:
And now my turn
Revision ChangesPath
1.156 +1 -16 jakarta-commons/jelly/project.xml
Index: project.xml
===
RCS file:
I'm in the process of building 1.0-RC1.
CVS has been tagged.
We really should document this process at some point :-)
--
http://www.multitask.com.au/people/dion/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
+1
David
--- Martin Cooper [EMAIL PROTECTED] wrote:
The Resources project has been in the sandbox for quite some time, and
is
essentially complete and almost ready for a release. Several projects
are
using it already, and others are ready to pick it up once it is
released.
Therefore
Before a 1.0 release, I would like to suggest an alternative Context
interface. Sorry, I realize I'm getting to the game a little late ;) I
think it is inappropriate for Context to extend from Map, because a Context
as defined in the Chain package isn't really a Map. Maps are great, but for
On Mon, 22 Nov 2004 14:42:53 +1100, Dion Gillard [EMAIL PROTECTED] wrote:
I'm in the process of building 1.0-RC1.
CVS has been tagged.
We really should document this process at some point :-)
Do you mean the general Commons component release process:
I disagree - Context should extend Map. I've used Chain in several
production applications and have enjoyed the methods Map brings to
Context. It makes it easy for the context to be exposed to external
applications that don't need to know any more than Map interfaces, and
therefore are not
+1
On Sun, 21 Nov 2004 15:01:02 -0800 (PST), Martin Cooper
[EMAIL PROTECTED] wrote:
I believe Chain is now sufficiently complete and stable to warrant an
official 1.0 release. There are no outstanding bug reports, and the
component is already in use in a number of projects.
The plan is to
Intermittent error with weak reference wrapper
--
Key: JELLY-166
URL: http://nagoya.apache.org/jira/browse/JELLY-166
Project: jelly
Type: Bug
Components: core / taglib.core
Versions: 1.0
Reporter: dion
Jelly doesn't have an Ant build file AFAIK, which this documentation assumes.
Reading through those documents, Maven's prepare/perform release cycle does
every step except for PGP signing which I do manually for distribution releases
but is a planned feature (and obviously the sanity checks that
Is there any reason not to modify the inheritence to remove the entity?
http://maven.apache.org/faq.html#using-entities
(I need to update this entry to mention that inheritence can be used as a
solution).
I think something like this in terms of hierarchy:
commons-build/project.xml
|
+-
On Mon, 22 Nov 2004 13:00:47 +0800, Brett Porter [EMAIL PROTECTED] wrote:
Is there any reason not to modify the inheritence to remove the entity?
Just the history of inheritance not quite working.
http://maven.apache.org/faq.html#using-entities
(I need to update this entry to mention that
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=32343.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
This sounds like an enhancement request to me. Are you really
suggesting that Chain should not be released until your specific
enhancement is endorsed and incorporated into the component? I'm
afraid I, for one, can't sign up for that.
Suggestions for enhancements should be made on separate
46 matches
Mail list logo
