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
On Mon, 2004-10-11 at 19:12, Oliver Zeigermann wrote:
Hi Simon,
I see you have put some energy on feedback! Thanks for that :)
Aargh! Our emails are crossing each other somewhere out in cyberspace
:-).
Actually, probably somewhere near Delhi, being roughly midway between
Germany and New
On Fri, 2004-10-08 at 11:27, Stephen Colebourne wrote:
One of the key items in the commons charter is allowing different solutions
to the same problem. So far, we have tended to avoid this (for example, I
took a conflicting primitives design elsewhere) however we should not block
this.
What
On Thu, 2004-09-23 at 09:24, robert burrell donkin wrote:
hi craig
unfortunately (or not) SetPropertiesRules has used beanutils.properties
since you imported it from struts. i'd be very reluctant to change it
for fear of breaking backwards compatibility.
Yep. I agree that BeanUtils is
On Tue, 2004-09-21 at 09:59, [EMAIL PROTECTED] wrote:
rdonkin 2004/09/20 14:59:23
Modified:digester build.xml
digester/src/java/org/apache/commons/digester
SetPropertiesRule.java
Log:
Allows exception throwing for mismatches to be switch
On Tue, 2004-09-21 at 17:06, Simon Kitching wrote:
On Tue, 2004-09-21 at 09:59, [EMAIL PROTECTED] wrote:
rdonkin 2004/09/20 14:59:23
Modified:digester build.xml
digester/src/java/org/apache/commons/digester
SetPropertiesRule.java
Log
On Mon, 2004-09-13 at 09:14, Simon Kitching wrote:
Hi Robert,
Thanks for all the work on the new release.
Is it ok with you if I now merge the changes made on the release branch
into CVS HEAD?
Ahh...I see you've already done it (on Friday).
So I guess there's no excuse for not working
Hi Robert,
Thanks for all the work on the new release.
Is it ok with you if I now merge the changes made on the release branch
into CVS HEAD?
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
On Mon, 2004-09-13 at 08:38, Reid Pinchback wrote:
The first performance-related patch I'll submit
shows how I approximate this. Mostly I try to
minimize how much JIT, GC, and differences in
inheritance hierarchy depth can distort the
comparison. The case I've put together is on
what
On Mon, 2004-09-13 at 11:42, Reid Pinchback wrote:
FYI, I've verified that yes, the Digester
substitution facilities in 1.6 can be used
to do the same kind of variable substitution
that Ant has. Just wanted to send in a note
so nobody wastes time tackling the same
problem. Once Simon has
On Sun, 2004-09-05 at 05:08, Gary Gregory wrote:
Simon and [digester],
Since we are on this topic; are there any other features implemented in
Digester that you feel should be in Java and therefore in [lang]?
No, there's nothing else I can think of.
Unless someone wishes to argue that the
On Mon, 2004-08-30 at 21:22, robert burrell donkin wrote:
i am suspect that it would be possible to use byte-code engineering to
wire up alternative implementations. the logging code wouldn't be
stripped but rather a new implementation would be wired in. of course,
the problem with this is
On Tue, 2004-08-31 at 13:27, Henri Yandell wrote:
On Thu, 26 Aug 2004, Craig McClanahan wrote:
You are asking two separate but related quesitons here, so they should
be addressed separately.
(1) Should libraries depend on *any* logging library?
It seems obvious to me that libraries
On Sat, 2004-08-28 at 11:42, Gary Gregory wrote:
Hello,
Since Interpolation is so close in intent to MessageFormat, I seems less
confusing to Java (as opposed to Perl) people to use a
MessageFormat-like name. For example MappedMessageFormat is not bad.
Look at java.text.MessageFormat
On Tue, 2004-08-24 at 10:13, robert burrell donkin wrote:
thanks for letting me know. i'll leave it a few more days so you (and
everyone else) has the chance to take a good look.
Hi,
Here's some fairly superficial stuff I found:
1. RELEASE-NOTES.txt file
(a) has a section describing how
On Thu, 2004-08-19 at 09:14, robert burrell donkin wrote:
digester 1.6.0 is the release candidate for the long awaited digester
release. this release contains numerous bug fixes as well as some very
useful new extensions including plugins (an intuitive framework for
dynamically modifiable
On Tue, 2004-08-17 at 09:44, robert burrell donkin wrote:
(i've not been too well recently but i'm better know and ready to push
the 1.6 release forward.)
Sorry to hear you haven't been well, but I'm glad to see you're back!
the source for org.apache.commons.digester.rss has been moved
On Thu, 2004-07-29 at 07:24, robert burrell donkin wrote:
On 26 Jul 2004, at 17:59, Craig McClanahan wrote:
On Mon, 26 Jul 2004 20:07:59 +1200, Simon Kitching
[EMAIL PROTECTED] wrote:
On Mon, 2004-07-26 at 19:13, robert burrell donkin wrote:
snip
And will the Digester 1.x series
On Mon, 2004-07-26 at 19:13, robert burrell donkin wrote:
hi simon
we all agree that the long term solution is to use an ArrayStack
packaged as part of digester. in fact, if we new then what we know now
about developing libraries, we have done this from the start.
i also agree that
On Mon, 2004-07-26 at 10:02, robert burrell donkin wrote:
On 25 Jul 2004, at 17:37, Craig McClanahan wrote:
On Sun, 25 Jul 2004 17:07:53 +1200, Simon Kitching
[EMAIL PROTECTED] wrote:
snip
Do you know of any containers that actually do use Digester and make
it
visible to containee
personally speaking, i'd gladly support anyone who had the energy to
push a digester 2 project forward. IMHO the digester one design has
been pushed just about as far as it can. starting digester 2 would
allow free refactoring without having to worry about binary
compatibility (and
On Mon, 2004-07-26 at 15:23, Craig McClanahan wrote:
For me, the most important decision is whether to roll back Craig
McClanahan's changes to the ArrayStack class. Craig added a copy of
ArrayStack as o.a.c.d.ArrayStack, to remove the dependency on
commons-collections. But this creates
On Fri, 2004-07-23 at 11:56, Simon Kitching wrote:
On Fri, 2004-07-23 at 10:09, robert burrell donkin wrote:
On 22 Jul 2004, at 01:27, Simon Kitching wrote:
On Thu, 2004-07-22 at 08:54, robert burrell donkin wrote:
I'm not generally a great supporter of binary compatibility. I
On Thu, 2004-07-22 at 08:54, robert burrell donkin wrote:
now that the beanutils release is reaching toward completion, i'm
turning towards the digester release. the release branch was created a
while ago but there are still some thing which need to be decided.
Woohoo!!
one important
Hi,
Just to note the obvious, the deployed site should generally be
generated from the cvs checkout for the last official release, not CVS
HEAD, because the jakarta sites should really reflect the state of the
currently released version.
This probably didn't need to be said...
Cheers,
Simon
On Thu, 2004-07-15 at 16:08, John Kane wrote:
Hi
I hit a minor problem with commons digester 1.5.
The version of digester I'm using is the version Struts 1.1
I read an XML file that contains the following tag definition
some-tag optional=true
On Windows XP it read the value
On Mon, 2004-06-14 at 07:48, robert burrell donkin wrote:
please remember to prefix with the name of the component.
On 13 Jun 2004, at 13:25, Hanson Char wrote:
The JavaBean spec 1.01 (Section 10.3) recommends in general to use
Beans.instantiate when creating beans. Any reason why the
On Thu, 2004-06-10 at 09:54, robert burrell donkin wrote:
this is a vote to approve the 1.6.0 release plan
(http://wiki.apache.org/jakarta-commons/
Digester_2f1_2e6_2e0ReleasePlan) and myself as release manager for this
release. i'll give this one 24 hours to run (before creating the tag).
Hi,
I have just made this commit:
On Tue, 2004-06-08 at 20:26, [EMAIL PROTECTED] wrote:
skitching2004/06/08 01:26:10
Modified:digester/src/java/org/apache/commons/digester Digester.java
Log:
Added javadoc to clear method about it being unsuitable for resetting
Digester for
On Wed, 2004-06-09 at 08:50, robert burrell donkin wrote:
i think that a digester 1.6.0 service release allowing digester to be
used with either commons collections 2.x or commons-collections 3.x
would be a very good idea. this release will focus on providing a
stable, compatible
Hi Alex,
On Sun, 2004-06-06 at 01:53, Alex Karasulu wrote:
Simon,
Is there support for all the wild card permutations such as * at the
head of a pattern, at the tail as well as anywhere in between. Also can
* be used more than once in a pattern?
No, none of the above is supported in the
Hi James,
On Tue, 2004-06-08 at 11:35, James Carman wrote:
How long does it usually take for a bug to be accepted? I submitted bug
29428 today along with a test case and patch for it, but it doesn't look
like any action has been taken on it.
The time it takes for someone to look at a bug
On Tue, 2004-06-08 at 09:13, robert burrell donkin wrote:
i've been pleased to see that simon's been hard at work with TODO lists
for 1.7 and 2.0 (at least, i think it's simon - whoever it is, what not
create a user profile then we'll all know).
Yep, that's me. I see that some WIKI edits
Hi,
Much to my surprise I recently discovered that the pattern * doesn't
work as a completely wild patternmatch in the RulesBase matching engine.
So attached is a patch that adds support for this, together with unit
tests.
I'm posting this rather than just committing the patch because I'm
Hi Robert,
Why exactly did you create the WithDefaultsRulesWrapper class? ie what
is the use case that caused you to create it?
I recently tried to associate a rule with the pattern *, with the
intention that the rule would fire if-and-only-if no other rule matched
the input element. It doesn't
On Wed, 2004-06-02 at 12:49, Gary Gregory wrote:
I think the confidence level for nightly builds could be
dramatically increased if a history would be provided with unit test
results in a similar fashion to the eclipse builds. For example, on the
page
On Wed, 2004-06-02 at 10:54, Gary Gregory wrote:
I agree with Michael.
When did this become is this a design goal? I am against it. :-(
It is one thing to say, I'll cut and paste [lang] code /into/ my own
project, and yes, I know about duplicating code, not getting bug fixes,
etc.
It
On Fri, 2004-05-21 at 07:18, Stephen Colebourne wrote:
This seems especially relevant with both collections and logging issues
recently.
From Lars Kuhne, developer of clirr
I'd say that the current version number 0.2 reflects the development
status pretty well: Alpha
* somewhat
On Thu, 2004-05-13 at 06:35, Alex Karasulu wrote:
From: Shapira, Yoav [EMAIL PROTECTED]
No I have not but I don't think an extra call is going to make
or break an application. Again everyone has valid concerns
about the approach and it may not be the best fit but worth
considering.
On Thu, 2004-05-13 at 01:32, Inger, Matthew wrote:
The only real issue i have with commons-logging is the
hardcoded list of loggers that are available, and having
to include the adapters for those loggers in our programs
no matter what. It would be nice to have a service provider
(read
On Thu, 2004-05-13 at 11:46, David Graham wrote:
--- Stephen Colebourne [EMAIL PROTECTED] wrote:
From: David Graham [EMAIL PROTECTED]
If I understand correctly, incompatible changes were made to
collections
after 3.0 and the next planned release is 3.1. So, since you haven't
Hi Alex,
On Wed, 2004-05-12 at 09:55, Alex Karasulu wrote:
Hi,
Sorry to step in late but has anyone considered the use of a generic
event callback interface for use in monitoring.
If a library has a couple of major events that it can report, then
callbacks are a nice idea.
However I see
Hi Robert,
On Wed, 2004-05-12 at 09:11, robert burrell donkin wrote:
1. if we're going to look at logging again, i'd prefer to think about
making beanutils a little more easy to use in a managed environment.
this means giving more programmatic control over logging.
Can you give some more
On Wed, 2004-05-12 at 00:53, David Graham wrote:
I was reluctantly in favor of copying certain Collections classes as a
temporary solution to removing that dependency but I don't see why we want
to permanently copy Logging classes to other projects. Commons Logging is
an abstraction for Log4j
On Wed, 2004-05-12 at 13:38, Noel J. Bergman wrote:
Sorry to step in late but has anyone considered the use of a generic
event callback interface for use in monitoring.
If a library has a couple of major events that it can report, then
callbacks are a nice idea.
However I see
On Mon, 2004-05-10 at 17:37, Simon Kitching wrote:
On Sun, 2004-05-09 at 06:16, matthew.hawthorne wrote:
[logging suggestion involving reflection]
Is this reasonable, or too much work?
Unfortunately, I think the delegation step is just too much overhead.
The log4j docs describe how
On Mon, 2004-05-10 at 17:37, Simon Kitching wrote:
On Sun, 2004-05-09 at 06:16, matthew.hawthorne wrote:
robert burrell donkin wrote:
funnily enough, if commons logging was to be created again, i'd (with
hindsight) consider something along those lines. the bridging
implementations
On Fri, 2004-05-07 at 17:41, matthew.hawthorne wrote:
Martin Cooper wrote:
I'm not going to -1 this, because it seems clear that there is support for
it, but frankly I just don't understand the mentality that says it's a good
thing to *not* share components that were designed from the
On Fri, 2004-05-07 at 12:07, Henri Yandell wrote:
On Thu, 6 May 2004, robert burrell donkin wrote:
community rules :)
if people are more comfortable with sourceforge (and two are so far, by
my count) then that's cool with me.
do any (potential) volunteers feel that the sandbox would
On Fri, 2004-05-07 at 13:58, David Blevins wrote:
On Thu, May 06, 2004 at 08:21:56AM -0400, Shapira, Yoav wrote:
is just a framework.
This is a getting a bit off-topic, but it's an interesting subject. Has
the Geronimo team quantified their desire, i.e. determined the upper
bound for
On Thu, 2004-05-06 at 09:53, Stephen Colebourne wrote:
From: robert burrell donkin [EMAIL PROTECTED]
In fact it's so horrible that I'm thinking of writing an alternative. A
simple app which takes two jars and generates an xml report of the API
differences between them (including listing
On Wed, 2004-05-05 at 09:09, robert burrell donkin wrote:
On 24 Apr 2004, at 04:19, Craig R. McClanahan wrote:
snip
From what I can see on TOMCAT-DEV, the Tomcat developers think that
there are backwards incompatibilities for Tomcat users (beyond any
issues that might affect Tomcat
On Wed, 2004-05-05 at 09:25, robert burrell donkin wrote:
On 24 Apr 2004, at 04:12, Craig R. McClanahan wrote:
Simon Kitching wrote:
snip
* move rss stuff to extras directory
-- will take care of this over the weekend.
i'm happy to do the actual moving. IMHO the real question
On Wed, 2004-05-05 at 00:51, Shapira, Yoav wrote:
Hi,
I wanted to point out a couple of points without delving into deep
discussion on their merits ;)
Tools of the pruner type exist, as Henri mentioned. I've used GenJar
(http://genjar.sourceforge.net/) in the past with some success, for
On Wed, 2004-05-05 at 11:57, Craig McClanahan wrote:
I like copying the class without a package rename as a medium-term step
while we deprecate and create a new public method that returns a
standard collection class instead of a [collections] class. The chances
of a bad change on the
On Mon, 2004-05-03 at 19:15, robert burrell donkin wrote:
On 2 May 2004, at 17:47, Henri Yandell wrote:
The only thing I can think of is the jdiff tool. As long as things are
only added, I would assume binary compatibility is kept?
So if jdiff were to create an xml report before the
Hi,
I've done about all I can to prepare Digester for a 1.6 release.
If there ever is to *be* a 1.6 release, someone else will need to step
up and do the remaining tasks now.
Remaining TO-DO:
* cvs version info: see later
* Move RSS code: Craig?
* Possible logging changes: Robert?
*
On Thu, 2004-04-22 at 08:48, paulo gaspar wrote:
Stephen Colebourne wrote:
IMO, the collections package:
1) should have really commonly used collections that are missing on the
java.util package and also
some usefull collections building blocks for especial cases;
2) should NOT be a
Hi all,
There was a recent change by Craig to add a copy of the collections
ArrayStack class into digester to make it independent of collections.
The critical emails seem to be:
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=107574718316162w=2
and
http://www.mail-archive.com/[EMAIL
On Tue, 2004-04-13 at 14:19, Simon Kitching wrote:
Hi,
Here's the list of things I think are remaining to do before a 1.6
release. I notice that the 1.5 release was done on 24-april-2003.
Wouldn't it be nice to get another release out before the year is up?
* resolve the mixed content
On Thu, 2004-04-15 at 10:10, Daniel F. Savarese wrote:
In message [EMAIL PROTECTED], Rory Winston w
rites:
Whereas the new Wiki is:
http://wiki.apache.org/old/CommonsNet/FrequentlyAskedQuestions
I'm confused. That page is not editable (it's listed as an immutable
page) and does not
On Fri, 2004-04-09 at 23:11, robert burrell donkin wrote:
On 9 Apr 2004, at 02:10, Craig McClanahan wrote:
matthew.hawthorne wrote:
Simon Kitching wrote:
What benefit is there in having this info in the source?
I can't currently see any:
* Developers can just use cvs status
Hmm..
On Tue, 2004-04-13 at 18:01, [EMAIL PROTECTED] wrote:
Please have a look at the attached file.
Sorry, Craig, but the pif file you attached won't run on my Debian
machine. Could you please re-write this in bash :-)
-
To
On Tue, 2004-04-13 at 18:21, Craig McClanahan wrote:
Simon Kitching wrote:
On Tue, 2004-04-13 at 18:01, [EMAIL PROTECTED] wrote:
Please have a look at the attached file.
I would be glad to if I'd actually sent it :-). Of course, it was
forged ...
Yeah, but it raises some
Hi all,
I recently took the time to have a good look at the new collections
library. It looks really really good - consistent, well-named,
comprehensive. Congrats to all involved.
I have a few minor javadoc patches to offer, the sort of things that (as
a newbie to collections) might have saved
On Wed, 2004-04-14 at 10:09, robert burrell donkin wrote:
i've been thinking about LogUtils. often, improved factoring of the
code allows further improvements. i'd prefer to allow the user more
flexibility in their choice of logging and i'd like to add this before
the 1.6 release (which i
On Wed, 2004-04-14 at 12:33, Simon Kitching wrote:
On Wed, 2004-04-14 at 10:09, robert burrell donkin wrote:
i've been thinking about LogUtils.
Despite all the above, if you have something in mind which is an
improvement on the current logging approach for digester, even if it
doesn't
On Wed, 2004-04-14 at 16:38, Craig McClanahan wrote:
Raines, David (Comm Lines, IT) wrote:
I can't seem to find a link to download the configuration package, even
though
I see javadocs and howtos on the jakarta site. Can someone tell me how I can
get the latest stable release of
Hi,
Here's the list of things I think are remaining to do before a 1.6
release. I notice that the 1.5 release was done on 24-april-2003.
Wouldn't it be nice to get another release out before the year is up?
If there's anything that's not on this list, please speak up!
* resolve the mixed
Hi Mark (or anyone else who might know the answer to this one):
I was looking at the ObjectCreateRule class, and saw that there was some
basic conditional logic in there that allows the caller to specify
that the object is to be passed to the method only if a certain
attribute is present on the
Hi,
I've created a branch called DIGESTER_INVOKE_METHOD_BRANCH, and
committed some code to it.
This is an implementation of a new variant of CallMethodRule.
This new variant invokes its target method as soon as all parameters are
available. As discussed earlier on this list, this makes behaviour
Hi,
A while ago I raised the idea of moving the RSS code currently in
digester to somewhere outside the main build, so that the vast majority
of users who don't want RSS support don't get it bundled.
For reference, Craig's +1 response is here:
On Wed, 2004-04-07 at 08:39, robert burrell donkin wrote:
a few disconnected and unordered observations about and comments on the
refactored plugins package:
5 consider whether to remove the resources parameter from:
the public PluginManager(PerDigesterResources r, PluginManager
Hi All,
I've just got stuck into removing the @author tags as agreed earlier (we
can discuss about adding @author Jakarta team or similar later).
But what should we do about the @version tag?
This is present on about 50% of files.
Is it needed? What purpose does it serve? What do other commons
On Thu, 2004-04-08 at 10:31, Simon Kitching wrote:
Hi All,
I've just got stuck into removing the @author tags as agreed earlier (we
can discuss about adding @author Jakarta team or similar later).
But what should we do about the @version tag?
This is present on about 50% of files
On Wed, 2004-04-07 at 05:20, Craig R. McClanahan wrote:
robert burrell donkin wrote:
On 5 Apr 2004, at 03:27, Simon Kitching wrote:
snip
You will see in CVS that Robert's new named stack pop method does
throw an EmptyStackException when an empty stack is popped, and I think
Hi Robert,
Thanks for taking the time to look at this.
On Wed, 2004-04-07 at 08:39, robert burrell donkin wrote:
a few disconnected and unordered observations about and comments on the
refactored plugins package:
1 it would be good to have a package html describing the strategies
On Tue, 2004-04-06 at 07:43, robert burrell donkin wrote:
On 5 Apr 2004, at 02:52, Simon Kitching wrote:
snip
What I'm proposing is not to change the Rule class [whose default
body(namespace,name,text) method delegates to the deprecated body(text)
etc].
What I'm proposing is to fix
On Mon, 2004-04-05 at 07:14, Alex Karasulu wrote:
Hi,
I was just looking at the digester code as I was writing another incarnation
of the digester pattern and noticed the pop() and peek() methods do not need
to catch exceptions. It is just cheaper to check the size of the stack
before the
On Mon, 2004-04-05 at 08:37, robert burrell donkin wrote:
as far as i'm concerned the major issue with a 1.6 is (and has been for
a while) finding a release manager. craig and i have different views on
who's eligible for this role. you might prefer craig's view's to mine
in this case.
I
was) provided that it was strongly
highlighted in the release documents.
i would be interest to hear what other people think about this one
(including lurking users).
- robert
On 3 Apr 2004, at 08:06, Simon Kitching wrote:
Hi,
I see that a number of Rule classes in digester are still
On Mon, 2004-04-05 at 14:13, Alex Karasulu wrote:
You really don't know how many times the empty stack is going to have pop or
peek called by a client. So this really is not a situation that we know is
only going happen once and a while. Cheaper comes from the fact that it
costs let to check
On Fri, 2004-03-12 at 11:35, robert burrell donkin wrote:
let me know when you're back and we'll have a think about backwards
compatible solutions to emmanuel's problem.
Well .. I'm back ;-)
I'm playing with an alternative to CallMethodRule (currently termed
InvokeMethodRule) which fires as
On Sun, 2004-03-28 at 18:33, Simon Kitching wrote:
Hi,
Ok, the refactored code for plugins is now committed on the
DIGESTER_PLUGINS_REFACTORING_BRANCH tag.
There is still a little work to go: the RuleFinder classes which load
dynamic rules via xmlplugins-style files just throw
Hi,
I see that a number of Rule classes in digester are still using the
deprecated versions of the begin/body/end methods.
In a minor-version release (1.5 - 1.6), are we allowed to change these
classes to use the newer methods?
Thanks,
Simon
Hi Robert,
On Thu, 2004-04-01 at 07:46, robert burrell donkin wrote:
i quite like author tags for aesthetic reasons :)
the reason why i favour including a link is that (judging from the
volume of personal email i've received from users over the years) there
are still quite a few users who
On Thu, 2004-04-01 at 18:37, Craig McClanahan wrote:
Simon Kitching wrote:
Hi,
Here's a simple patch that I think would make digester more efficient,
by avoiding unnecessary calls to rules.getMatch().
I like the idea in general, but would ask one favor ... could you try
the modified
+0
And thanks for all the hard work - it looks great.
On Thu, 2004-04-01 at 09:44, Mark R. Diggory wrote:
All,
We'd like to have a vote to verify everyone is in agreement to push the
commons-mavenized site over to replace the existing commons top level
site.
On Wed, 2004-03-31 at 10:55, Edelson, Justin wrote:
Simon - Sorry I haven't had a chance to respond to your email. I was
actually more concentrating on answering your question about use-cases,
but it sounds like I don't need to sell this need as much as I thought I
did (at least for now).
On Thu, 2004-04-01 at 18:23, Simon Kitching wrote:
Attached is a working solution based on my original proposal. It is
integrated into Digester rather than being a subclass. I think the
changes are simple enough, and performance impact low enough, that
integrating this into the mainline is ok
Hi,
I notice that Xalan has implemented a new class:
org.apache.xalan.Version
with a method
static String getVersion()
and also a static main method which prints the version#.
See:
http://xml.apache.org/xalan-j/apidocs/org/apache/xalan/Version.html
The comment associated with this
On Tue, 2004-03-30 at 18:33, Craig McClanahan wrote:
Noel J. Bergman wrote:
This class implements the upcoming standard of having
org.apache.project-name.Version.getVersion() be a standard way to get
version information.
That's news to me. I suspect it is news to most. As far as I know,
Hi,
We had a discussion about author tags a while ago. The general consensus
was that individuals should no longer be listed in these tags [NB: not
an official vote]. I think this is now also apache policy?
Robert Donkin suggested using them to credit the commons team, with
the benefit that a
On Thu, 2004-03-25 at 12:01, Simon Kitching wrote:
On Thu, 2004-03-25 at 04:36, Edelson, Justin wrote:
Since coding these changes, I've rethought whether or not this needs to
be a subclass - since @text() can't be a legal XML element, existing
code shouldn't be affected. After starting
On Tue, 2004-03-30 at 18:11, matthew.hawthorne wrote:
Isn't this sort of thing supposed to be handled by manifest files? I
might be oversimplifying.
The initial problem that Xalan faced was people reporting bugs in xalan
when they weren't actually running the version they thought they were,
On Sat, 2004-03-27 at 09:45, Craig R. McClanahan wrote:
Quoting Simon Kitching [EMAIL PROTECTED]:
Hi,
I've got a significant patch ready for Digester's plugins module.
It refactors the existing code that currently locates the dynamic rules
for a plugin into a Strategy pattern
Hi,
Ok, the refactored code for plugins is now committed on the
DIGESTER_PLUGINS_REFACTORING_BRANCH tag.
There is still a little work to go: the RuleFinder classes which load
dynamic rules via xmlplugins-style files just throw an unimplemented
exception at the moment. But that's not important to
Hi,
I've got a significant patch ready for Digester's plugins module.
It refactors the existing code that currently locates the dynamic rules
for a plugin into a Strategy pattern with a number of predefined
strategies matching the old code.
The patch also fixes a number of outstanding issues,
On Thu, 2004-03-25 at 04:36, Edelson, Justin wrote:
Since coding these changes, I've rethought whether or not this needs to
be a subclass - since @text() can't be a legal XML element, existing
code shouldn't be affected. After starting to duplicate all of the
existing Digester test cases to
On Wed, 2004-03-24 at 12:36, matthew.hawthorne wrote:
Mark R. Diggory wrote:
What are our thoughts on migrating to subversion? I've not even had time
to try it out myself. Though I have it on my list.
I've been using it at work for about 6 months and I like it a lot.
Being able to easily
601 - 700 of 787 matches
Mail list logo
