Is this for a product blog or personal blogging about a product? Are these
official product information? If so, perhaps this should be addressed in
the overall site-dev context. We have discussed having a roller-based blog
tied to announce@ lists, and providing product information feeds.
Resolved tends to be something that the developer sets, when they feel that
it has been fixed. Closed tends to be something that testers set after
verification. But if this doesn't suit the workflow, it can be changed.
See Message-ID: <[EMAIL PROTECTED]> in
infrastructure@ from 30May2006, and th
Bryce L Nordgren wrote:
> I'm in the process of stealing (possibly forking) the dormant project
> commons-events.
> I'd really rather keep it separate and refer to it by a dependency.
> Would there be any interest in reviving this project
Yes.
> I hope to sweet talk someone here into taking com
> Rearranging Jakarta into different islands than the islands of today
> doesn't convince me that the project will see any change in community
> overlap
As you may have noticed on general@incubator.apache.org, I've raised this
issue in terms of communities based upon codebase oversight and ontolog
Phil Steitz wrote:
> Any comments on this?
> http://issues.apache.org/bugzilla/show_bug.cgi?id=38073
I'd go with the cleaner solution, and document the possible problem in the
release notes for anyone whom it might impact.
--- Noel
--
> How does the list feel about cleaning up foo()'s to this.foo()'s?
IMO, a waste of time. Java isn't Smalltalk, and this isn't self.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
> PGP is the thing that stops me doing releases. I accept that it's
> important, but that hasn't helped me grokk how to do it.
Really simple. I automate it in my build script. And documented it on the
wiki.
--- Noel
-
Sandy McArthur wrote:
> Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> > > i'd like to propose that we accept this donation.
> > Provided that you do all of the necessaries vis-a-vis IP Clearance, +1.
> Took a while to make sure but I'm confident it's
> i'd like to propose that we accept this donation.
Provided that you do all of the necessaries vis-a-vis IP Clearance, +1.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PRO
Simon Kitching wrote:
> My conclusion at the end of the last round of debate on that was that
> their "enterprise logging" stuff did not belong in JCL at all.
Such as? I think that we should support the functionality that has been
added to Java, such as tracing levels. And we should support loc
> Comments?
Only to suggest since we're talking about JCL v2, with new architecture and
API design, that we (re-)engage the folks from IBM who wanted to look at the
needs for enterprise logging.
--- Noel
-
To unsubscrib
Frank W. Zammetti wrote:
> Has any thought been given to, or has any work been done already, to
> creating a Javascript-based client-side version of Digester? I'm
> starting on a new project soon where I'll potentially have to be doing a
> fair amount of client-side XML parsing, and it occurs to
repository@apache.org is probably your best bet.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Martin's valid points aside, if you just want to copy the classes from IO,
you can use external in SVN.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> Well, since nobody answered me, I went ahead and just tried
> importing the code into the sandbox SVN repository
What is this code and do we have the appropriate docs filed?
As I understand it, and we have been through this before with even a
Director's own code, if this is a new codebase that
Torsten Curdt wrote:
> ...I just wanted to point out that incubator not only exists
> due to legal reasons. (actually I am not sure if that was the
> main in reason in the first place at all) If it was, we would
> not need it for internally started projects.
Actually, we don't need to use it for
Brett Porter wrote:
> "A copy of several classes from the Apache Ant codebase, restructured
> into a reusable library without dependence on Ant itself."
Sounds fine. Now that we know the history, even the original commit comment
makes sense, but when you put the original against the e-mail archiv
Brett Porter wrote:
> Noel J. Bergman wrote:
> > I re-read the commit messages, and no it was not entirely
> > clear, at least not in terms of the clarity I'd want for
> > IP clearance. The concern is tracking provenance.
> Ok, do I need to edit the commit message?
Niklas Gustavsson wrote:
> Should a CLA/grant be needed, I would of course be happy to work that out.
> Would a CLA be needed for future patches or would attaching them to a
> Bugzilla entry be acceptable?
If you are going to contribute on an on-going basis, as CLA would be best,
yes. Otherwise,
Brett Porter wrote:
> given Noel's email on commons-exec, I think it would be good to
> talk about the similarities of the sandbox and the incubator and
> determine if both are needed and how they can help each other.
They are probably both needed, since the sandbox is typically used for
internal
Brett Porter wrote:
> The "contribution" comes almost entirely from the Ant codebase. Sorry if
> I didn't make that clear from the commit message.
I re-read the commit messages, and no it was not entirely clear, at least
not in terms of the clarity I'd want for IP clearance. The concern is
track
Re: http://svn.apache.org/repos/asf/jakarta/commons/sandbox/exec/trunk/
Whoa, hello!
This thing is labeled as an initial contribution, and the SVN tree was just
created for it in July. It doesn't matter if it is a sandbox project or
not. New codebases *MUST* be imported through the Incubator, a
> anyone strongly object to me making the dependency
> on the servlet api optional
I'd object if you DIDN'T.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> a Jakarta subproject is fine with me.
I posted a proposal to the PMC list. Although, in retrospect, it should
probably have been posted to [EMAIL PROTECTED] No need for it on the PMC list.
Do we have enough PMC members here to vote (albeit on general@)?
--- Noel
---
> i think that either martin or noel were going to head over to taglibs
Wasn't me. Martin, possibly.
It wouldn't take much to set this up, so why not propose this to the PMC and
get it started?
--- Noel
-
To unsubscri
Mark Diggory wrote:
> I would recommend not getting bogged down in taglibs and focus more on
> establishing the project with the parties that are interested, motivated
> and willing to put in the time. Once well established, I would bank on
> the eventual consolidation of the taglibs project by "w
As Martin alluded, there has been talk about a WebApps Commons, which could
house commonly reusable servlets, taglibs and filters. I still support such
a grouping.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Fo
robert burrell donkin wrote:
> Noel J. Bergman wrote:
> > You might want to involve Ben Laurie in this discussion.
>
> that'd be great. what's the best way to organise this?
Well, cc'ing him as I've done would be one way to invite Ben to participate.
:-) An
robert burrell donkin wrote:
> Dave Brondsema wrote:
> > It would be useful, I think, to get a keyid from a signature, fetch and
> > update keys from a keyserver, and get names and email addresses from a
> > public key.
> automatically fetching a public key from a server and then presenting
> th
As configured in SVN,
[/jakarta/commons]
@jakarta-commons = rw
[/jakarta/commons/sandbox]
@jakarta-commons-sandbox = rw
anyone who has karma for Jakarta Commons has karma for Jakarta Commons
Sandbox. Therefore, to make maintaining the lists easier, I changed them so
that the jakarta-com
> could someone please grant karma to Stefan ?
Done.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+1
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> members of the Maven, Ant and Repository teams have been thinking
> about adding PGP support to their respective projects for a while,
> but so far neither of those projects has made any real attempt to
> do so.
> The goal is a library that provides a simple API to PGP sign files
> (or streams?)
Alistair Young wrote:
> I was wondering what the process was for proposing a new commons package.
You're likely to need to come through the Incubator.
> I have Novell eDir LDAP/NDAP java code
Ownership?
And are you aware of the Apache Directory project?
--- Noel
-
Martin Cooper wrote:
> Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> > I would enthusiastically support a webapp commons
> > as a separate project, to which we would accept
> > servlets, tag libs, etc.
> I too would support the creation of this type of commons projec
> I too would like to have a webdav servlet in commons.
(B
(BI would not, but I would enthusiastically support a webapp commons as a
(Bseparate project, to which we would accept servlets, tag libs, etc.
(B
(B--- Noel
(B
(B
(B--
Remy wrote:
> My plan for JULI is to:
What is JULI? I know JCL, UGLI, Log4J, j.u.logging ... hmmm ... is JULI an
acronym for j.u.l-integration?
> Is there any pace for this in the logging project, or should I
> seek another home ?
If not in Logging, perhaps in Jakarta Commons? It appears that
Ceki,
> Remy Maucherat said,
> > At this point, the only productive thing that could happen
> > is if log4j adopted the java.util.logging API as the
> > logging API for log4j.next.
> It doesn't make any sense for log4j.next to adopt
> java.util.logging API.
Why not? Provide specifics. If we a
> I'm looking into a problem with commons-beanutils and commons-logging
> related to "undeploying" or "reloading" components running within
> j2ee-like frameworks.
Have you looked at JMX? Specifically, JSR-77?
> This article: http://www.onjava.com/pub/a/onjava/2001/06/26/ejb.html
Appears more d
Ceki Gülcü wrote:
> Seriously, aren't you sick of JCL exploding with an
> LogConfigurationException at the most inappropriate times?
Actually, a few of us working on the eyebrowse migration kind of feel that
way about Log4J today. log4j-1.1.3 and current don't have the same
behavior. For detail
> Not sure how long [CVS] stays either.
The CVS repositories stick around for Committers, but are generally removed
from public view to prevent confusion.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additio
daniel.vlad wrote:
> I just wanted to point out that these personalization components can be
> used for non web applications as well.
Your current propose seems webapp specific.
> Not all applications are portals, in fact the opposite is probably true
> So, why restricting the use of personaliz
daniel.vlad wrote:
> JSR 168 focuses on Portlet specifications, and unfortunately,
> personalization rules such as those presented in this proposal
> and not part of the API.
Per-user portlet preferences are part of the Portlet Specificiation
(JSR-168). If you've not noticed, you might want to r
Please see JSR-168, JetSpeed, and other portal projects. I don't see a use for
a new personalization package for web applications that is not compatible with
Portals, and does not provide suitable implementation for portals, even if it
can be repurposed for standard web applications.
-
> 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
wanting to build all of Commons is not the
> I thought Jakarta would have its own SVN repository
Not a chance.
--- Noel
smime.p7s
Description: S/MIME cryptographic signature
Paulo Gaspar wrote:
> I don't think we are discounting the value of the original proposal but
> simply questioning if it should be implemented exactly as proposed - a
> process you should be familiar with since it is quite common about
> proposals presented at Apache projects.
David Graham wrote:
Simon Kitching wrote:
> Noel J. Bergman wrote:
> > It disturbs me that what seems to me to be a reasonable and small set of
> > requirements --- along with what appears to have been considerable
> > forethought based upon real world issues, and experiences supportin
> Aspect oriented tools obsolete the need for this kind of logging method.
We've been able to implement this sort of thing for years using "OpenJava".
You're all using the OpenJava pre-processor, right? ;-)
Translation: I'll accept this reasoning when AOP tools are part of every
JDK. Which shou
Richard Sitze wrote:
> As a real example, the axis community uses globalized messages.
A lot of products do, as I see on a regular basis, so I definitely support
your interest in this feature.
However, I view logging as separate from content generation. I'd like to
see the mechanism pluggable.
It disturbs me that what seems to me to be a reasonable and small set of
requirements --- along with what appears to have been considerable
forethought based upon real world issues, and experiences supporting many
developers --- appears to be discounted a bit too out of hand. I hope my
perception
Matt Sgarlata wrote:
> Richard Sitze wrote:
> >info(Class callingClass,
> > String methodName,
> > String messageID);
> I don't understand why the calling class and method name are included.
Probably because the overhead of getting them from the stack
+1
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Eric Pugh wrote:
> I'd guess that the JSF jar's are not distributable on IBiblio,
> just like the JavaMail ones?
Check the license, but if it is the SBCL, then the restriction applies.
This would be a good reason to use MyFaces, of course. :-)
Martin Cooper wrote:
> One alternative, I suppose,
Simon Kitching wrote:
> If each subproject has a 'tags'/'branches' directory, then doesn't it
> become impossible to check out the latest source of *all* the commons
> projects without ending up with a copy of every branch of that project
> ever made?
You would check out the trunk for each compon
> Can you comment on the admin-side advantages of svn ?
Elimination of the need for shell accounts, and the ability to shift load
from the core infrastructure team to the PMCs. Trivial project movement.
And since we sometimes have to ... <> ... help recover from people
playing around with ",v" fi
Henri Yandell wrote:
> Noel J. Bergman wrote:
> > Henri Yandell wrote:
> >
> > > I think a pretty fair target for Jakarta is to be fully in SVN by the
> > > end of next year; unless there are reasons to move quicker.
> >
> > End of NEXT year?! I do
Henri Yandell wrote:
> I think a pretty fair target for Jakarta is to be fully in SVN by the
> end of next year; unless there are reasons to move quicker.
End of NEXT year?! I do hope you're kidding.
--- Noel
-
To unsu
> > 6) should I just delete the /jakarta-commons-sandbox/email directory, or
> > leave the folder and a note pointing to the promotion? What about the
> > website as well? I think for [configuration] we just deleted both.
> The ideal scenario would be to use "cvs delete" on all the sandbox
> fil
Why not move the code to iBatis? And what does GUMP have to do with
anything? If you can maintain it elsewhere, you can maintain it here. You
have as much access to GUMP descriptors as anyone.
--- Noel
-
To unsubscrib
+1
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Oliver Zeigermann wrote:
> I understand your fears.
> However, xmlio is not a mapper to Java objects, you just
> receiver augmented SAX call backs.
Is this something that could be pitched to Digester and XMLBeans to use
under the covers? What would be the pros/cons of their adopting this
packag
Johnson Leung <[EMAIL PROTECTED]> wrote:
> I don't know why i can read all of yr communication email.
Our records show:
Sun Aug 17 09:39:26 2003 + [EMAIL PROTECTED]
That means that on Sunday, August 17 at 9:39 PDT, that e-mail address
requested AND CONFIRMED that it wished to subscribe to our
+1 to keeping Ant support. It is the de facto standard. And our own
dogfood. :-)
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> I want to make a file upload utility.
> I am looking for a solution w/o using any third party APIs
> like oreilly's or Jakarta Commons utils.
> 'why not commons' is because of the business need to create a
> full fledged solution with proper documentation for the coding
> and the architecture.
Adjusted /etc/groups to match avail. Notifying PMC.
--- Noel
-Original Message-
From: Thomas Dudziak [mailto:[EMAIL PROTECTED]
Sent: Monday, July 05, 2004 9:08
To: [EMAIL PROTECTED]
Subject: Cannot access developer CVS
Hi,
I have commit rights for jakarta commons ([EMAIL PROTE
Move Jakarta-Commons to SVN, and use svn (re)move as necessary.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> there's what looks to be a lost lock file in the chain directory.
Not quite. Please post the actual error message next time.
cvs server: failed to create lock directory for
`/home/cvs/jakarta-commons/chain' \
(/home/cvs/jakarta-commons/chain/#cvs.lock): Permission denied
indicated that the
Stephen Colebourne wrote:
> Rodney Waldhoff wrote:
> > For the record, while I'm +0 on moving toward JDK 1.5 support within
> > collections, I'm certainly -1 on abandoning JDK 1.4 support in the
> > near future.
> For the record, I'm -1 to abandoning JDK1.2 support in [collections] ;-)
I'll +1 tho
> Our build already has to copy around, put on classpaths for unit tests,
> distribute, etc, ten (10) apache jars, now you're telling me that one of
> these is going to blow up into SEVEN?! This is not progress for us.
Do you use all of the ORO engines? We just use Perl, for example. And one
cou
> > But more cooperation/integration testing would be nice. Does the James
> > or tomcat group do a JDK1.3 compatibility check?
> i've been wondering for a little while whether it'd be possible to use
> gump for extended compatibility tests.
I would certainly hope so. :-)
--- Noel
--
Dirk Verbeeck wrote:
> DBCP 1.1 was also compiled with JDK1.4 so I think we're safe for now.
> I don't follow the f(T) thing.
Example:
JDK 1.3 has: public synchronized StringBuffer append(Object obj)
JDK 1.4 adds: public synchronized StringBuffer append(StringBuffer sb)
The following code:
Now there are some questions how to handle the regexp thing:
[X] Avoid dependency to jdk1.4.
JDK 1.3 should be the highest minimum standard unless the code absolutely
positively needs java.nio.
--- Noel
-
To unsubscribe
> DBCP 1.2.1 is a maintenance release to restore full JDK 1.3 compatibility.
> [X] +1 Go for it!
Was there anything similar in Pool? And can we compile the release packages
with JDK 1.3?
--- Noel
-
To unsubscribe, e-ma
+1
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> DBCP 1.2.1 is a maintenance release to restore full JDK 1.3 compatibility.
>
> Cast your votes please:
>
> [X] +1 Go for it!
> [ ] -1 I found another issue
And I urge everyone to please COMPILE all releasables with
**
> Leo's in.
> Could someone with avail access add him into Commons?
Done. Leo, please verify.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Leo,
Let's get you on-board. Also, have you had a chance to work with JAM on the
merger?
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
You know the drill. I'll start off with a +1.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> A lot of these wiki changes come from apache committers.
> Do you think it is possible to tag these changes so we
> can skip reviewing these for vandalism?
Do you skip reviewing CVS commits because they came from a fellow committer?
I hope people are reviewing changes. And the Wiki changes don'
> Do you think it's helpfull to see an email for EVERY
> trivial edit in Jakarta_Commons_Wiki ?
> I think one message per 24 hours, like one sent by
> codehaus's confluence would be sufficient.
I'm not particularly keen to see wiki vandalism sitting untouched for 24
hours, or longer if people don
Release Commons-DBCP 1.2
-
[X] +1 I support this release and will help
[ ] +0 I support this release but am unable to help
[ ] -0 I do not support this release
[ ] -1 I do not support this release, and here are my reasons:
-
Release Commons-Pool 1.2
-
[X] +1 I support this release and will help
[ ] +0 I support this release but am unable to help
[ ] -0 I do not support this release
[ ] -1 I do not support this release, and here are my reasons:
-
Robert,
For clarity, Commons Logging 1.0.4 will support both new and prior Log4J
versions? If so, my +1.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[X] +1 Yes, release the patch
[ ] +0
[ ] -0
[ ] -1 No, because
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Craig R. McClanahan wrote:
> Noel J. Bergman wrote:
>>> The upcoming version 1.0.4 of commons-logging has an AvalonLogger
>> So we create an AvalonLogger around our component's logger, and pass
>> that to any object that uses commons-logging.
> I'm travel
> ( Let's hope some Velocity folk can help out next:
Shouldn't:
[javac]
/data3/gump/jakarta-velocity/bin/src/org/apache/velocity/runtime/log/SimpleL
og4JLogSystem.java:119: cannot resolve symbol
[javac] symbol : method setPriority (org.apache.log4j.Level)
[javac] location: class org.
> Which is why GUMP should allow projects to specify dependencies
> on SPECIFIC versions of other products
A project may want to track the latest FOO, which forces it to pickup a
newer BAR, too, even though its own use of BAR might want to stay stable.
There are all sorts of possibly dependenc
One thing I've noticed is that as a rule of thumb, when something breaks in
GUMP, people tell the dependents to update. Hopefully, as GUMP pervades the
mindset for people, there will be equal pressure on dependencies to
stablize.
This is *not* to say that Log4J is doing anything wrong. I'm makin
> I wish projects had stopped using deprecated stuff a year ago, heck
> ... or two.
"If it ain't broke, don't fix it."
Stable projects do not like making change for changes sake. Have you
noticed that although Sun deprecates methods, they rarely remove them unless
there is a real security concer
> we could also use reflection at all to call those log( methods,
> but this might result in an performance loss.
Is logging is THAT performance critical?
--- Noel
smime.p7s
Description: S/MIME cryptographic signature
Go for it.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> What you are telling, it seems, is that there is a key practice at
> Apaache, amazing!
Distributions are to be signed. Individuals jars aren't code signed,
though. There is on-going work to establish an ASF Certificate Authority
server, and that will help to further the authenticated infrastru
> if people don't find utility from this big list of Commons,
> bug I propose we just tell Bugzilla to stop sending it to
> commons-dev.
It would be shorter if people closed bugs. ;-)
--- Noel
-
To unsubscribe, e-mail:
> We could add a 'packaged project' a fixed set of jars we don't
> (including can't) build, for project "XYZ-version" see:
> http://brutus.apache.org/gump/public/packages.html
> Alternatively, you could add/reference the jars in your CVS, and
> add you own XYZ-version, kinda like james-server.x
> Gump has some of this already. It can use a CVS tag (or SVN branch)
> of some module to allow this.
Which would work really well if Avalon had tagged their stuff prior to
complaints about why tagging is "sort of" vital, but all that we have are
the current jars. Not even the Avalon folks who la
> My impression was, GUMP always use the cvs-head to build the
> dependencies - and fixing the dependency to a given release
> is not the intention of GUMP.
>From experience, I can tell you that I welcome the new ability to fix
certain dependencies. For example, the Avalon Project has made API ch
[X] +1 Yes!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> I understand the desire to not having projects use snapshots, but the
> reality is you just sometimes need to build against head. The geronimo
> team tries to limit snapshots to projects that do instep releases with
> geronimo but that is still about 30 modules spread across 4 projects.
Why use
> Think of all the projects out there that are using apache
> snapshots that would have to add the apache repo to their
> project. Not only is this a lot of traffic to apache, I
> think it also sets a bad precedent for other projects.
One question is whether or not we want people to be using snap
1 - 100 of 353 matches
Mail list logo
