r files. jakarta-commons is the perfect place to start enforcing
this in the Apache umbrella. Early-bound dependencies are bad, m'kay.
We need to somehow get people started on the notion of using
deprecation, and supporting the contracts that they have already provided.
Scott Sanders
Ted Husted wrote:
> I think we should focus on making the build process flexible, and let
> "users" start with binary releases.
>
This makes the barrier to entry even lower, with no build step. I love it!
Scott Sanders
a classname
attribute on the element. I would think that Digester is the same way,
or at least provides the same functionality ;-)
Scott Sanders
like it and
can push other people toward it. After it becomes a little more clear,
I will propose it to Commons.
Thanks
Scott Sanders
ad, Peter, you have planted the seed of the ant
task with xml repositories. Eventually, I would envision that the ant
task just goes over to Ant, and the xml stuff becomes its own 'project',
just maintaining metadata about all the jars in the world...
Scott Sanders
> Let me know when you're ready to commit, and I'll set up the appropriate
> karma.
>
Thanks, Craig. I will be ready to start comitting tomorrow afternoon
(3-4pm PDT). My userid is sanders.
> Another thing we have to consider is dependencies between jars. ie if jar1
> depends on jar2, which depends on jar3 version 1.0 etc. First things first
> though ;)
>
Baby steps ;-)
[EMAIL PROTECTED] wrote:
> sanders 01/04/12 23:08:37
>
> jakarta-commons-sandbox/cjan - New directory
So, I was able to create the directory, but I cannot commit anything to
it. Someone let me know when I can ;-)
Cheers
Scott Sanders
Craig R. McClanahan wrote:
>
> On Thu, 12 Apr 2001, Scott Sanders wrote:
>
>
>>> Another thing we have to consider is dependencies between jars. ie if jar1
>>> depends on jar2, which depends on jar3 version 1.0 etc. First things first
>&g
> Done.
>
> Craig
Thanks again, Craig.
Scott
se that, then you can
create the site and other types of documentation. Stylesheets are
already in existence to do the work.
The only problem is choosing the subset of DocBook ;-)
Scott Sanders
tabase thing, when nagoya is set up and running already.
I would hope that problems common to all communities could be solved and
implemented by all communities ;-) But that is just me, and I could be
wrong.
Scott Sanders
>>> so true it is sad ;(
>>
>>
>> I am only to assume that Costin is joking ;-) (At least I hope he is joking)
>
>
> you would hope wouldn't you? ;)
I most definetly hope so ;-0
> Whether he is joking there is more truth in it than I am comfortable with.
> Have a look at what projects dupli
> Seriously - I wonder if we could make an Anakia stylesheet that worked
> with a DocBook DTD...
>
That would make sense to me.
Scott
Craig R. McClanahan wrote:
> As I'm starting to build individual Commons packages, having to maintain
> individual build.properties files is sorta tiresome -- yet, I might want
> to have properties that are unique to my "jakarta-commons" environment
> that are different from my user properties.
>
o use XmlMapper? Should I move it
into the sandbox?
Scott Sanders
Craig R. McClanahan wrote:
>
> On Mon, 16 Apr 2001, Scott Sanders wrote:
>
>
>> I am going to need to use something for CJAN to create Java Objects from
>> XML.
>>
>> I watched this go around the list a while back, and several solutions
>> were b
n the
jakarta-struts CVS tree. I am proposing to move it to commons as it is
a very useful component that can be used in many projects.
Scott Sanders
---
Proposal for Digester Package
(0) Rationale
Many Jakarta products read XML configuration fil
Craig R. McClanahan wrote:
> One nitpick along with my +1 -- the property setting stuff relies on the
> code that is now in "beanutils" in Commons already.
>
> Craig
And JAXP as well, I suppose? ;-) Sorry I missed that.
Scott Sanders wrote:
> Craig R. McClanahan wrote:
>
>> One nitpick along with my +1 -- the property setting stuff relies on the
>> code that is now in "beanutils" in Commons already.
>>
>> Craig
>
>
> And JAXP as well, I suppose? ;-) S
Geir Magnusson Jr. wrote:
> Scott Sanders wrote:
>
>> Here's the Digester proposal, directly edited from the DBCP proposal, so
>> if something looks funny, well... ;-)
>>
>> The Digester package provides a method for mapping arbitrary XML to
>> enable t
Craig R. McClanahan wrote:
> Sorry, didn't notice one other thing:
>
> On Mon, 16 Apr 2001, Scott Sanders wrote:
>
>
>> [snip]
>> (1.5) Interaction With Other Packages
>>
>> Digester relies on:
>>
>> * Java Development Kit (Versio
to beanutils?
I am fine with that. It is in a sense some generic jav object
manipulation routines. Since it will use beanutils' code, the release
jar makes sense to include both for digester, but what about the other
way around?
Scott Sanders
Geir Magnusson Jr. wrote:
> Scott Sanders wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>
>>
>>> I'd be involved if we do this, so feel free to add me to the committer
>>> list, but can we think about maybe combining a few things together?
>
>> Also, do we need to move the ArrayStack to collections?
>>
>>
>
> Did that one already (plus a test class).
>
> Craig
Excellent, Smithers ;-)
her, IMHO.
One might argue that you can package all of commons in a 'mega-release',
but that is just packaging at a higher level, the sub-sub-projects would
still operate 'on their own', right?
Scott Sanders
>> Would it make any sense to move it into beanutils?
>>
>
>
> You mean Digester itself? I don't think so, if we are talking about
> fine-grained components. Consider:
> * Beanutils is very narrowly focused on low-level introspection based
> functionality, and can be used underneath multipl
Geir Magnusson Jr. wrote:
> Scott Sanders wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>
>>> Scott Sanders wrote:
>>>
>>>
>>>> Geir Magnusson Jr. wrote:
>>>>
>>>>
>>>>
>>>>
>&g
upon the org.apache.struts.digester package contained in the
jakarta-struts CVS tree. I am proposing to move it to commons as it is
a very useful component that can be used in many projects.
Scott Sanders
---
Proposal for Digester Packag
want to do a little homework to see how we can approrpriately
> expand the scope.
>
> geir
>
>
> Scott Sanders wrote:
>
>> OK, here is the updated proposal. I think that Digester is the perfect
>> example of a project that uses Common's components to build ev
> My plan (at least for Struts), and assuming Digester is approved as a
> Commons package, is as follows:
>
> * For Struts 1.0 (final release before JavaOne), deprecate the
> corresponding code inside Struts, but continue to use it.
>
> * For Struts 1.1, switch to dependence on the "jakarta-co
anything else.
I am willing to let anyone help, just let the list know what you are
doing so we don't do the same thing.
That said, I am going to work on the build.xml/properties to get the
thing to compile.
Scott Sanders
Geir Magnusson Jr. wrote:
> Any reason why not? It's src, of sorts.
>
> One less directory at the top level.
>
> geir
Fine with me. Go for it. I just copied from collection, IIRC.
Scott
> I *think* I get to blame this one on Vincent :-). It was his suggestion
> that configuration files go in "conf" rather than "src/conf".
>
Doesn't it make more sense to be under /src though, as the MANIFEST.MF
file uses susbstitution, so it should be considered a 'source file'.
Scott
Craig,
Was it your intention to remove the method:
peek(int n)
from ArrayStack?
I am compiling the Digester and it asks to:
stack.peek(n)
which does not exist. What should I do?
Scott Sanders
Since I am not a committer yet, this is a patch to get Digester to
compile using collections instead of Struts ;-)
Index: src/java/org/apache/commons/collections/ArrayStack.java
===
RCS file:
/home/cvs/jakarta-commons/collections/s
http://xml.apache.org/bin/xml-xerces/xerces-1.2.jar"/>
http://xml.apache.org/bin/xml-xerces/xerces-1.3.1.jar"/>
Thoughts?
Scott Sanders
This was an interesting thought from the Struts dev list regarding a
test method for the db conn pool. Does DBCP have something like this?
Would something like this be useful? I would think so.
Scott
Original Message
Subject: Re: Data Connection Pool, solution?
Date: Tue, 1
gh. I am designing it this way to see how it will
work. Maybe it ultimately becomes a dynamic resource ;-)
>
> Ok, I think that should be enough for the moment :-)
Feel free to jump in with more. More heads are better than just mine ;-)
Scott Sanders
> (3) Required Jakarta-Commons Resources
>
> * CVS Repository - New directory |digester| in the |jakarta-commons|
> CVS repository.
>
One small issue ;-) the new directory in jakarta-commons would probably
want to be something other than digester ;-)
Scott
Reasoning for "No Version Number":
- Allows build.xml files that use these JARs to define properties
(commons-beanutils.jar=${commons-beanutils.home}/commons-beanutils.jar)
without worrying about version numbers
- We're going to maintain API stability, r
Geir Magnusson Jr. wrote:
> James Strachan wrote:
>
>> From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
>>
>>> Re the new additions we are currently talking about, we can simply tag
>>> for this milestone before they go in there and put them in after the
>>> milestone.
>>
>> Sounds a good idea.
id directory in the sandbox?
Scott Sanders
ge for it to be
> dealt with via patterns and wildcards, things might be better.
>
Has there been a decision reached on this? I am +1 on including version
number in the jar, per Geir's suggestion, although I am not a committer.
Scott Sanders
nt in the strategy of
all java open source development, and I want to see all those bloddy
jars disappear from CVS!
Anyway, I am happy to do the release for digester, since I imported it,
but it does depend upon beanutils and collections, so I would really
hope for a release there as well
I, as the wannabe committer, vote +1, even though it does not yet count.
I think the triad of collections, beanutils, and digester are a great
example of what commons can be.
Scott Sanders
Craig R. McClanahan wrote:
> The Digester module (useful, among other things, for reading XML-ba
Modified:digester/src/java/org/apache/commons/digester
CallMethodRule.java ObjectCreateRule.java
SetNextRule.java SetTopRule.java
Log:
Update to JDK 1.2 method of loading classes that is multiple classloader
> Yep ... and why don't you go ahead and sign yourself up in the STATUS.html
> file for digester -- I'll add your karma there so you can keep on
> maintaining and enhancing after it moves over.
>
I am already there, since I wrote it and all ;-)
Scott
d encourage the Ant crowd to do the same thing. (And
> I'm going to take my own advice on Struts for contributed stuff that we
> haven't had time to integrate yet :-).
>
> Craig
I will try and initiate that over on Ant-dev. My intention was to
finish the functionality to enable the xpath task to make it into the
distribution, so an ant-sandox is appropriate.
Scott Sanders
Peter Donald wrote:
> Hi,
>
> At 03:14 2/5/01 -0700, Scott Sanders wrote:
>
>> I will try and initiate that over on Ant-dev. My intention was to
>> finish the functionality to enable the xpath task to make it into the
>> distribution, so an ant-sandox is app
o to try this out on. Who wants to see
it in their project first?
Maybe I should post to general@ to see if anyone is interested?
Later,
Scott Sanders
hat uses the command line tool to
> fetch ant and dependencies into a local repository, and uses it to start
> the build script. The idea is that you can make a small installer to
> get ant's jars, and then invoke ant to do something more complicated
> like get things from CVS, compile, all the wonderful thing ant does...
>
> Anyhow, it's late and I'm beat. If there is positive interest to see
> this in detail, I can put it into sandbox, but would want to do a bit of
> refactoring and cleanup...
>
I would like to see it. I am sure others would like to as well.
> I hope to do some real ant use-testing in a project jason is working on
> - a riff on the Gump idea - I think it will be important to see what to
> see what ant integration really requires, and garner some use-practice
> with it.
>
Let's see it and get the discussion going,
Scott Sanders
>> You do have to start somewhere, right? So you are starting at:
>> A JDK
>> An internet connection
>> Your tiny jar file
>>
>> Not bas for a start. I just add Ant to that list.
>
>
> The issue I have with ant, and I realize that this is orthogonal to the
> wishes of the ant community,
Sam Ruby wrote:
> Geir Magnusson wrote:
>
>> I am very pro XML myself. I think think that since the API takes care
>> of all details though, putting everything behind a Repository class, it
>> could be implemented via gerbils...
>
>
> I'd like to see an instance proof of that myself.
>
> Sma
Geir Magnusson Jr. wrote:
> Really? I thought that would mean that it was added to the PATH, and
> ANT_HOME was setup.
>
Doh ;-( Actually forgot that I did that...
> *If* you need to download a jar - I think that an important use-case is
> the working developer, and having a local repository
Geir Magnusson Jr. wrote:
> Scott Sanders wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>
>>> I am going to do a few things more to it, and then I can drop it into
>>> the sandbox so people can play with it. It's pretty ugly right now :)
>
Craig R. McClanahan wrote:
> On Mon, 7 May 2001, Vincent Massol wrote:
>> Instead of viewing the repository of jars as simply a set of files, I would
>> prefer to view it as a set of services, all related to publishing and
>> querying files. Examples of services would be :
>> - get a version of a
Geir Magnusson Jr. wrote:
> Vincent Massol wrote:
>
>> Instead of viewing the repository of jars as simply a set of files, I would
>> prefer to view it as a set of services, all related to publishing and
>> querying files. Examples of services would be :
>> - get a version of a jar,
>> - list al
> 2) I don't think web services are the way, as the notion of repository
> doesn't necessarily mean 'central'. You can have a repository on your
> own machine, that your projects and apps use. You can then just
> synchronize once in a while if you care. For example, 'released apps'
> that use i
Avalon has this, so I am also for housing it in Avalon,
as an example of the framework, something like the (new)
jakarta-turbine-jyve format.
Scott Sanders
Craig R. McClanahan wrote:
> Does anyone know of work towards a generic package for background job
> scheduling that would live inside
warnings. I
think that we should go beyond this later, though.
Scott Sanders
Craig R. McClanahan wrote:
>
> On Sat, 12 May 2001, Scott Sanders wrote:
>
>
>> Hello all,
>>
>> I have updated Digester to use the SAX2 interfaces, but I have a few
>> questions.
>>
>> Basically, when we have a start element, should Digest
>>> After these changes, does Digester remain compatible with JAXP/1.0 APIs?
>>> That is important for Struts users who will want to be able to plug in
>>> whatever parser they want.
>>
>> No, it does not. JAXP 1.0 uses SAX 1, and JAXP uses SAX2. The
>> PROPOSAL.html states that Digester wil
stence_1_0.dtd");
>
> Am I doing something wrong, or is this a bug in the docs?
This is a bug in the docs. Thanks for pointing it out. The workaround
for now until I patch this is to call register like this:
digester.register("whateverTheSystemIDIs",
getClass.getResource("/org/apache/").toString());
or something to that effect.
Scott Sanders
thout them knowing ;-)
My intention is to allow the definition of test cases in XML, using
digester to create the test cases, then execute and output the result to
XML, styling to HTML with XSLT.
Scott Sanders
> Sorry for the slow reply but our support guys have been fiddling with
> the
I am +1 on a 1.0 release of these packages.
Being a +1, I am willing to help, as then I could also get Digester to a
1.0 fairly soon afterward.
I think that we just blaze a trail, document it, and see what people
think ;-)
Let me know what to help with,
Scott Sanders
> I'd like to
emulate that. How do I?
Or do I have to set up an empty constructor, and then add a setName()?
Thanks,
Scott Sanders
rify either the whole file against the golden file, or just xpath
expressions. Then we log the result to XML using ant and JUnit, then
format the results to HTML for the dev group to see.
How was that?
Scott Sanders
class access level.
We changed the code to check for the context class loader first,
assuming that would be better from a security perspective.
Scott Sanders
Jeff Turner wrote:
> Hi,
>
> I'm curious as to why the Digester code always tries to use the thread's
> classlo
Craig R. McClanahan wrote:
>
> On Wed, 30 May 2001, Scott Sanders wrote:
>
>
>> Craig will correct me if I am wrong, but the idea is that in a server
>> environment, the server container *may* set the conxtext class loader
>> for you (at the webapp level
This seems reasonable. I will add it.
Thanks,
Scott Sanders
>
> Hi,
>
> I figured out my problem getting the digester to work in WL6.0:
>
> Apparently Weblogic is brain-dead when it comes to supporting JAXP1.1
> (they have everything built in as JAXP1.0). So when th
I think that is fine, and IMHO, the optimal solution, ie eating our dog
food.
Just remember that Digester relies on beanutils and collections as well as
JAXP1.1, so it might be a size issue, but I doubt it.
We are really building up a value-chain in commons ;-)
Scott Sanders
- Original
Done. Digester now has a constructor that sets the SAXParser. Try it out
and tell me how it goes. Sorry it took so long, just got back and got
access back as well.
Scott Sanders
>Thanks guys! -- I'll enjoy not maintaining my own branch!
>
>James
I think that I saw this as well. Can you try switching parsers and seeing
if that works. It was so long ago, and I thought it was configuration on my
end, but IIRC, xerces did not work and crimson did. If so, I might have
something to debug.
Scott Sanders
- Original Message -
From
Craig,
I would like to help with the release of Digester, but I have never done a
release. The closest thing I have done is created an installer for JServ
1.something. What do I need to read to come up to speed on this. This is
assuming that you want the help ;-)
Scott Sanders
Excellent. I will move forward some time after that...
Scott
> I will have some time to formalize this process next week (as we agreed a
> while back that I would do), but this week my time will be focused on
> Tomcat.
> RE: [Vote] Vote for a new Cactus committerHi,
>
> One thing I find strange is that the response is actually stuffed in the
> method object (GetMethod, ...). So you use the method object for both
> setting the request and accessing the result. I would think it is better
to
> separate the 2 and pr
> RE: [Vote] Vote for a new Cactus committerHi,
>
> The RFC 2109 states that the domain part for setting a cookie is optional
> but the Cookie.java class mandates a domain and throws an exception if
none
> is specified.
>
> Could we add a new constructor with no domain or rather only provide a
> c
Essentially it was a very small subset of what xmlunit will be, so I used
some of xmlunit's code on the backend of httpclient...
Scott
> Hey Scott,
>
> Looks like what you are implementing is HttpUnit (or something very
> similar), isn't it ? :)
> Cheers,
> -Vincent
>
> > > Hi,
> > >
> > > One
Ah, this was when I converted to SAX 2.0. I did not know that the localName
would be null. This would possibly explain why Xerces would not process my
rules, but Crimson would, I would hope.
As far as the proposal, I think that is fine. Someone will speak up if it
is not...
Scott
PS I will w
default being false (do not use context class loader), I was
wondering if that should be true or not? All of my use of Digester is in a
web application context, so I would prefer it to be true. What are other
people's thoughts on the matter.
Scott Sanders
> Uhhh...the previous patch
client, and I also use log4j in the same
project. But I would rather see the interceptor approach taken, because my
use of http-client needs to be completly transparent to the application
administration. This is indeed the way to go, and I intend to push digester
in this direction as well. It can afford the same level of functionality,
while allowing the end user more control.
Scott Sanders
I haven't done much but bug fixes, but I am here as well ;-)
Scott Sanders
- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 28, 2001 8:45 AM
Subject: Re: earth-to-digester
> Well, I wrote
Bring it on!
Scott
- Original Message -
From: "robert burrell donkin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 29, 2001 10:50 AM
Subject: Re: earth-to-digester
> intelligent life on digester - amazing! ;-)
>
> sorry for the lame humour but one of the consequence
Done.
Thanks robert!
Scott
- Original Message -
From: "robert burrell donkin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 29, 2001 1:57 PM
Subject: [PATCH] org/apache/commons/digester/package.html
> this patch replaces org.apache.struts.digester with
> org.apache.co
Did you go here: http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/
Recently the cvs server moved around, so the link you saw somewhere was
probably wrong. Could you let me know what page the faulty link was on, or
just submit a patch ;-)
Thanks
Scott
- Original Message -
From:
> There are many features which could (and probably will) be added to the
HTTP
> client, but I think many people (including myself, since the Slide WebDAV
> client is an extension of this HTTP client) need a stable version on which
> they could base their work on.
Agree 100%. I have already been
system such as httpclient,
digester, collections, beanutils, etc.
Scott Sanders
- Original Message -
From: Waldhoff, Rodney
To: '[EMAIL PROTECTED]'
Sent: Wednesday, August 01, 2001 9:50 AM
Subject: RE: [httpclient] log4j redux
> -rw-r--r-- 1 544 cgu29103 Aug 1 1
Title: RE: [httpclient] [VOTE] HTTP client 1.0 release
Rodney, the veto does apply without a vote.
You committed something that Remy feels he needs to -1, that is perfectly valid
using the commit then review (CTR) model of development. He gave a good
reason, IMHO, and being a committer he
logging again (was RE: [httpclient] [VOTE] HTTP client 1.0 release)That's
what the sandbox is for, no?
Scott
- Original Message -
From: Waldhoff, Rodney
To: '[EMAIL PROTECTED]'
Sent: Thursday, August 02, 2001 4:19 PM
Subject: logging again (was RE: [httpclient] [VOTE] HTTP client 1.0 rel
Remy, I intend to attempt to have digester use this same structure, unless
Craig has some reason not to ;-) I would hope that this could benefit all
commons components. Long live commons!
Scott Sanders
> +1 for this change, since it allows clean log-less operation.
>
> Is it p
Done.
- Original Message -
From: "robert burrell donkin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 02, 2001 12:26 PM
Subject: [PATCH] jakarta-commons website broken links
> here's that patch for the website broken links (again)
>
> yes - it's the xml in xdocs th
This is the idea that I had implemented in CJAN as an Ant Task. You defined
${local.repo} and ${remote.repo} and then did a get of say velocity (the
latest was the default to get, or you could specify a version), check it
out and steal it for jjar. This is exactly what I was wanting to do, and
with jjar?
Scott
- Original Message -
From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 1:11 PM
Subject: Re: Central Repository for JARs
> Scott Sanders wrote:
> >
> > This is the idea that I had imp
Jason,
As long as you have an addProject method on the container and on the
projects, you should be able to do it with one set of rules as Craig has
explained.
If you have any questions, just send me some code (or pointers to code), and
I can help you.
- Original Message -
From: "Crai
RE: cvs commit:
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient
HttpClient.java HttpMethod.java HttpMethodBase.java> IMHO the concept of a
commons is DOA unless external
> interfaces are viewed as contracts.
Right. For *released* versions of components. Stuff that's in developm
che/commons/httpclient
HttpClient.java HttpMethod.java HttpMethodBase.java
> Scott Sanders wrote:
> >
> > Why are we holding an *unreleased* commons component to a higher
> > standard of stability than anything else?
>
> (1) Because they are common. Presumed to be a core depen
Can I get 3 +1s for Dirk Verbeeck <[EMAIL PROTECTED]> as committer on
httpclient. He helped write the original submission, he shouldn't have to
submit patches ;-)
Scott Sanders
Admin question. I give my +1, no problem, but does it count across commons?
I mean, I am a committer on digester, can I vote a committer in on
httpclient. Better yet, am I allowed to commit code on httpclient?
Scott
- Original Message -
From: "Rodney Waldhoff" <[EMAIL PROTECTED]>
To: <
+1. I have done some work in this area, and Latka goes further than
mine.
Does anyone have a problem with me adding xpath validations?
Scott Sanders
-Original Message-
From: Morgan Delagrange [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 17, 2001 1:49 PM
To: commons
Subject: [VOTE
1 - 100 of 124 matches
Mail list logo
