[jira] Updated: (JELLY-150) j:forEach tag not properly using varStatus attribute

The following issue has been updated: Updater: dion gillard (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Oct 2004 11:35 PM Comment: Here's a patch that doesn't require loop status, and passes the same tests. Comments? Changes: Attachment changed to jelly-150-dg.txt

cvs commit: jakarta-commons-sandbox/convert build.xml

craigmcc2004/10/04 22:36:07 Modified:convert build.xml Log: Work around stupid Maven bug that generates absolute paths sometimes. Nightly builds should start tonight at: http://cvs.apache.org/builds/jakarta-commons/nightly/commons-convert/ Revision ChangesPath 1

Re: sandbox proposal. Events

On Mon, 04 Oct 2004 15:06:51 -0400, Mike Stanley <[EMAIL PROTECTED]> wrote: > On Mon, 2004-10-04 at 13:40, Craig McClanahan wrote: > > > Perhaps the EventResult instance that encapsulates the result and any > > exception could also encapsulate the Method instance that was actually > > called? Tha

Re: autobuild of convert and modeler

build.xml added. Feel free to add to the list. Hen On Mon, 4 Oct 2004 20:11:07 -0700, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Mon, 04 Oct 2004 22:03:36 -0500, Vic Cekvenich > <[EMAIL PROTECTED]> wrote: > > I just found modeler (too late a night for me) jars. > > I guess convert is not re

cvs commit: jakarta-commons-sandbox/convert build.xml

bayard 2004/10/04 20:25:39 Added: convert build.xml Log: maven generated build file for the nightly build Revision ChangesPath 1.1 jakarta-commons-sandbox/convert/build.xml Index: build.xml ==

Re: autobuild of convert and modeler

On Mon, 04 Oct 2004 22:03:36 -0500, Vic Cekvenich <[EMAIL PROTECTED]> wrote: > I just found modeler (too late a night for me) jars. > I guess convert is not ready for prime time (or I can find it). > .V The [convert] developers have not provided an Ant-compatible build.xml file, so I can't add it

Re: autobuild of convert and modeler

I just found modeler (too late a night for me) jars. I guess convert is not ready for prime time (or I can find it). .V Vic Cekvenich wrote: (I conitnualy find high value dimonds in commons.) Most commons and sandbox has a build. Modeler (JMX) and convert do not have a build that I can find. Yes I

autobuild of convert and modeler

(I conitnualy find high value dimonds in commons.) Most commons and sandbox has a build. Modeler (JMX) and convert do not have a build that I can find. Yes I can build it from cvs but... it be nice to have builds in the releases so people can just get the jar. tia, .V

RE: (JELLY-150) j:forEach tag not properly using varStatus attribute

Ben, Now I see what you did with the patch. See http://jakarta.apache.org/commons/patches.html for the diff command. All you have to do is include the new files on the end of cvs diff -u and they'll be a part of the patch. Hans -Original Message- From: Ben Anderson [mailto:[EMAIL PROTECT

[jira] Commented: (JELLY-150) j:forEach tag not properly using varStatus attribute

The following comment has been added to this issue: Author: Hans Gilde Created: Mon, 4 Oct 2004 5:27 PM Body: I'm opposed to doing this. It will mean that we have to bundle the whole JSTL JAR, just to use one interface. Unless we're going to go full JSTL couldn't we just inc

cvs commit: jakarta-commons/jelly commonDependencies.ent

dion2004/10/04 17:21:44 Modified:jelly/xdocs changes.xml jellycommonDependencies.ent Log: Move to beanutils 1.7.0 Revision ChangesPath 1.20 +1 -0 jakarta-commons/jelly/xdocs/changes.xml Index: changes.xml ===

cvs commit: jakarta-commons/jelly/jelly-tags/betwixt/xdocs changes.xml

dion2004/10/04 17:08:11 Modified:jelly/jelly-tags/betwixt/xdocs changes.xml Log: Upgrade to betwixt 0.6 Revision ChangesPath 1.4 +1 -0 jakarta-commons/jelly/jelly-tags/betwixt/xdocs/changes.xml Index: changes.xml =

cvs commit: jakarta-commons/jelly/jelly-tags/betwixt project.xml

dion2004/10/04 17:07:39 Modified:jelly/jelly-tags/betwixt project.xml Log: Upgrade to betwixt 0.6 Revision ChangesPath 1.23 +1 -1 jakarta-commons/jelly/jelly-tags/betwixt/project.xml Index: project.xml =

[jira] Commented: (JELLY-150) j:forEach tag not properly using varStatus attribute

The following comment has been added to this issue: Author: dion gillard Created: Mon, 4 Oct 2004 5:04 PM Body: What license is the JSTL jar under? Does the standard taglib ship with this interface? - View this com

[jira] Commented: (JELLY-150) j:forEach tag not properly using varStatus attribute

The following comment has been added to this issue: Author: dion gillard Created: Mon, 4 Oct 2004 5:04 PM Body: If we need LoopTagStatus, we should add it to our dependencies, not include it in our source code. -

RE: sandbox proposal. Events

Hi. On Mon, 2004-10-04 at 18:16, Michael Heuer wrote: > On Mon, 4 Oct 2004, Mike Stanley wrote: > > > On Mon, 2004-10-04 at 15:14, Jung, Eric wrote: > > > > > You might also consider using java.util.EventListener, > > > java.util.EventListenerProxy, and java.util.TooManyListenersException as > >

[ANNOUNCEMENT] Commons Betwixt 0.6 Released

The Jakarta Commons Team is pleased to announce that Betwixt 0.6 is now available. Betwixt is a flexible, dynamic, start-from-java object-XML mapper. Betwixt release 0.6 is the first release containing the refactored codebase featuring an improved design. This is a service release for those who

cvs commit: jakarta-commons/betwixt/xdocs index.xml navigation.xml tasks.xml

rdonkin 2004/10/04 15:27:13 Modified:betwixt RELEASE-NOTES.txt project.xml betwixt/src/java/org/apache/commons/betwixt ElementDescriptor.java XMLIntrospector.java betwixt/src/java/org/apache/commons/betwixt/digester

DO NOT REPLY [Bug 31534] - validateRequired.js uses unsupported DOM method for validation.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 31534] New: - validateRequired.js uses unsupported DOM method for validation.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

RE: sandbox proposal. Events

On Mon, 4 Oct 2004, Mike Stanley wrote: > On Mon, 2004-10-04 at 15:14, Jung, Eric wrote: > > > You might also consider using java.util.EventListener, > > java.util.EventListenerProxy, and java.util.TooManyListenersException as > > appropriate. All of these were introduced in JSDK 1.3. > > > Event

cvs commit: jakarta-commons/httpclient release_notes.txt

olegk 2004/10/04 15:08:46 Modified:httpclient Tag: HTTPCLIENT_2_0_BRANCH release_notes.txt Log: ContentLengthInputStream no longer supports mark() & reset() methods. Old broken implementation removed. Contributed by Eric Johnson Reviewed by Oleg Kalnichevski Revision

cvs commit: jakarta-commons/httpclient release_notes.txt

olegk 2004/10/04 15:08:18 Modified:httpclient release_notes.txt Log: ContentLengthInputStream no longer supports mark() & reset() methods. Old broken implementation removed. Contributed by Eric Johnson Reviewed by Oleg Kalnichevski Revision ChangesPath 1.37

cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient ContentLengthInputStream.java

olegk 2004/10/04 15:05:44 Modified:httpclient/src/java/org/apache/commons/httpclient ContentLengthInputStream.java Log: ContentLengthInputStream no longer supports mark() & reset() methods. Old broken implementation removed. Contributed by Eric Johnson

cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient ContentLengthInputStream.java

olegk 2004/10/04 15:04:34 Modified:httpclient/src/java/org/apache/commons/httpclient Tag: HTTPCLIENT_2_0_BRANCH ContentLengthInputStream.java Log: ContentLengthInputStream no longer supports mark() & reset() methods. Old broken implementation removed.

Re: [Configuration] autoSave causing FileNotFoundException

Hi Mark, thank you for reporting this issue, I just checked in a fix. Let us know how it works for you. Emmanuel Bourg Mark Roth wrote: I believe I've found a bug. When trying to use autoSave, jakarta-commons-configuration gives me the following error: - java.io.FileNotFoundException: file

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/derived BeanWithSecrets.java

rdonkin 2004/10/04 14:53:07 Added: betwixt/src/test/org/apache/commons/betwixt/derived BeanWithSecrets.java Log: Tests for property suppression strategy and move to supress class property using suppression strategy Revision ChangesPath 1.1

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/derived TestWriteClass.java

rdonkin 2004/10/04 14:52:40 Added: betwixt/src/test/org/apache/commons/betwixt/derived TestWriteClass.java Log: Tests for property suppression strategy and move to supress class property using suppression strategy Revision ChangesPath 1.1

cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/strategy PropertySuppressionStrategy.java

rdonkin 2004/10/04 14:52:13 Added: betwixt/src/java/org/apache/commons/betwixt/strategy PropertySuppressionStrategy.java Log: Tests for property suppression strategy and move to supress class property using suppression strategy Revision ChangesPat

cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/strategy DefaultObjectStringConverter.java

rdonkin 2004/10/04 14:50:35 Modified:betwixt/src/java/org/apache/commons/betwixt BeanProperty.java IntrospectionConfiguration.java XMLIntrospector.java betwixt/src/java/org/apache/commons/betwixt/digester

cvs commit: jakarta-commons/betwixt/xdocs/guide binding.xml

rdonkin 2004/10/04 14:49:20 Modified:betwixt/xdocs tasks.xml betwixt/xdocs/guide binding.xml Log: Documentation about property supression strategy Revision ChangesPath 1.37 +2 -0 jakarta-commons/betwixt/xdocs/tasks.xml Index: tasks.xml

cvs commit: jakarta-commons/configuration/xdocs changes.xml

ebourg 2004/10/04 14:45:11 Modified:configuration/src/java/org/apache/commons/configuration AbstractFileConfiguration.java configuration/src/test/org/apache/commons/configuration TestXMLConfiguration.java conf

DO NOT REPLY [Bug 25661] - [configuration] Reloadable configurations

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 27686] - [configuration] INIConfiguration

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 30858] - [configuration] PropertyConfiguration.save() does not take basePath into account

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 31532] New: - [configuration] Implement autoSave for all file based configurations

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [configuration] JNDIConfiguration should close() its NamingEnumeration on exception

Jung, Eric wrote: With this in mind, I'd like to see NamingEnumerations wrapped in try/catch blocks with NamingEnumeration.close() called in the catch. Any thoughts? Thanks for listening. Good point, however according to the javadoc calling close() is not mandatory, it gives just a hint to the und

cvs commit: jakarta-commons/configuration/xdocs changes.xml

ebourg 2004/10/04 13:06:09 Modified:configuration/src/java/org/apache/commons/configuration JNDIConfiguration.java configuration/xdocs changes.xml Log: All NamingEnumerations in JNDIConfiguraiton are now properly closed (Suggested by Eric Jung

Re: sandbox proposal. Events

On Mon, 2004-10-04 at 15:47, Mario Ivankovits wrote: > Mike Stanley wrote: > > >Thought about the Hash approach too. That won't suffice. > > > Havent looked at [event] now, but the first thing about how to handle > results which comes into my mind was a ResultHandler - what if you just > prov

RE: sandbox proposal. Events

On Mon, 2004-10-04 at 15:14, Jung, Eric wrote: > Not sure what EventResult is (I was referring to a generic return object, > not mentioning any specific class or interface for a return type), As am I. EventResults is simply a container for generic return objects. More specific than a List or

Re: sandbox proposal. Events

Mike Stanley wrote: Thought about the Hash approach too. That won't suffice. Havent looked at [event] now, but the first thing about how to handle results which comes into my mind was a ResultHandler - what if you just provide a way to set a ResultHandler - a interface with a method like Result

DO NOT REPLY [Bug 30799] - [configuration] Set wrong property when call XMLConfiguration.setProperty

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

[jira] Commented: (JELLY-150) j:forEach tag not properly using varStatus attribute

The following comment has been added to this issue: Author: Ben Anderson Created: Mon, 4 Oct 2004 12:40 PM Body: The interface is defined here: http://java.sun.com/products/jsp/jstl/1.1/docs/api/javax/servlet/jsp/jstl/core/LoopTagSupport.html There was some discussion following th

cvs commit: jakarta-commons/configuration/xdocs changes.xml

ebourg 2004/10/04 12:35:45 Modified:configuration/src/java/org/apache/commons/configuration XMLConfiguration.java configuration/xdocs changes.xml Log: Fixed bug Bug 30799, thanks to Rory Winston for spotting the source of the issue ! Revis

Re: (JELLY-150) j:forEach tag not properly using varStatus attribute

Le 4 oct. 04, à 15:36, Ben Anderson a écrit : you make a valid point. I had just copied that interface from the jakarta-taglibs project. It is an interface - not a class. I'll admit, I don't know too much about licensing. I was just assuming that it's legal to create a physical manifestion of

RE: sandbox proposal. Events

Not sure what EventResult is (I was referring to a generic return object, not mentioning any specific class or interface for a return type), but while we're on the subject, have you considered java.util.EventObject as the elements in the list/array? This is what I use in my "event chain" implementa

RE: sandbox proposal. Events

On Mon, 2004-10-04 at 13:40, Jung, Eric wrote: > I see. Good point. So how about the original array (or List) idea instead? > Do you see any problems with that? EventResult will probably be the best. It would have an List of single results (delegate method, when it was executed, return value, e

Re: sandbox proposal. Events

On Mon, 2004-10-04 at 13:40, Craig McClanahan wrote: > Perhaps the EventResult instance that encapsulates the result and any > exception could also encapsulate the Method instance that was actually > called? That way, an array or List of EventResults would still be > understandable. And, if you

DO NOT REPLY [Bug 30799] - [configuration] Set wrong property when call XMLConfiguration.setProperty

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

cvs commit: jakarta-commons/configuration/src/test/org/apache/commons/configuration TestXMLConfiguration.java

ebourg 2004/10/04 11:14:59 Modified:configuration/src/test/org/apache/commons/configuration TestXMLConfiguration.java Log: Test case for Bug 30799 Revision ChangesPath 1.12 +9 -1 jakarta-commons/configuration/src/test/org/apache/commons

Re: sandbox proposal. Events

Perhaps the EventResult instance that encapsulates the result and any exception could also encapsulate the Method instance that was actually called? That way, an array or List of EventResults would still be understandable. And, if you only cared about the last one, it's easy to find. On the othe

RE: sandbox proposal. Events

I see. Good point. So how about the original array (or List) idea instead? Do you see any problems with that? -Original Message- From: Mike Stanley [mailto:[EMAIL PROTECTED] Sent: Monday, October 04, 2004 1:36 PM To: Jakarta Commons Developers List Subject: RE: sandbox proposal. Events

RE: sandbox proposal. Events

Thought about the Hash approach too. That won't suffice. I don't want to limit the number of times a method can be added to an "event chain". Take for example, the ability to manipulate an image (not the best example - but it adequately demonstrates what I'm talking about): It would be possible

RE: sandbox proposal. Events

I use an "event handler chain" (my term for the pattern you describe) in an application right now that requires the handler(s) which failed be identified after the event handler chain completes. [The chain may or may not continue processing if one handler fails]. The best way I thought to do this w

RE: sandbox proposal. Events

On Mon, 2004-10-04 at 12:42, Jung, Eric wrote: > >If the delegate methods return a value, > >the last value would be returned (this is the > > behavior of the .NET approach. I'm open to other suggestions). > > How about the option of either (1) receiveing the last value or (2) > receiving an ar

Re: sandbox proposal. Events

Craig, Cool. I'll look into these and begin extracting the library for contribution. Perhaps [delegate] as an alternate name but if [event] is not active, i think that would be more ideal. I'll look at that more closely. Maybe they can be combined. I'd also like to talk more about pipeline,

RE: sandbox proposal. Events

>If the delegate methods return a value, >the last value would be returned (this is the > behavior of the .NET approach. I'm open to other suggestions). How about the option of either (1) receiveing the last value or (2) receiving an array of values, where each array element represents a return v

Re: sandbox proposal. Events

Mike, This pattern does indeed sound interesting. You might also want to take a look at the [pipeline] sandbox package (contributed by Kris Nuttycombe) that I checked in over the weekend. It offers a different tack on handling asynchronous events, and is also investigating how an interaction wit

sandbox proposal. Events

I've implemented a pattern, somewhat based off the .NET event and delegate pattern, however the pattern is also commonly seen in frameworks (to some extent). At a high level, the pattern is made up of two objects: - Event - DelegateMethod The Event is a container for DelegateMethods. Delegate

DO NOT REPLY [Bug 31528] New: - Initialize ArrayIntList with int[]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

cvs commit: jakarta-commons-sandbox/i18n/xdocs/images i18n-logo-white.png

dflorey 2004/10/04 06:41:11 Added: i18n/lib xml-im-exporter1.1.jar xml-im-exporter.license i18n/src/java/org/apache/commons/i18n MessageManager.java MessageNotFoundException.java LocalizedBundle.java LocalizedText.java Loca

cvs commit: jakarta-commons-sandbox/i18n/src/java/org/apache - New directory

dflorey 2004/10/04 06:40:59 jakarta-commons-sandbox/i18n/src/java/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/i18n/src/java/org/apache/commons/i18n - New directory

dflorey 2004/10/04 06:40:59 jakarta-commons-sandbox/i18n/src/java/org/apache/commons/i18n - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/i18n/lib - New directory

dflorey 2004/10/04 06:40:59 jakarta-commons-sandbox/i18n/lib - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/i18n/src/java/org/apache/commons - New directory

dflorey 2004/10/04 06:40:59 jakarta-commons-sandbox/i18n/src/java/org/apache/commons - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/i18n/src/java/org - New directory

dflorey 2004/10/04 06:40:59 jakarta-commons-sandbox/i18n/src/java/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/i18n/xdocs/images - New directory

dflorey 2004/10/04 06:40:59 jakarta-commons-sandbox/i18n/xdocs/images - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/i18n/src/java - New directory

dflorey 2004/10/04 06:40:59 jakarta-commons-sandbox/i18n/src/java - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/i18n/src - New directory

dflorey 2004/10/04 06:40:59 jakarta-commons-sandbox/i18n/src - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/i18n - New directory

dflorey 2004/10/04 06:40:59 jakarta-commons-sandbox/i18n - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/i18n/xdocs - New directory

dflorey 2004/10/04 06:40:59 jakarta-commons-sandbox/i18n/xdocs - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

New componenent: i18n

Hi folks, I'm a Slide committer for a while and now extracted a tiny package called i18n that I found to be very useful in several projects in the past. I wanted to add it to the sandbox, but unfortunately didn't even manage to build the site with maven correctly. Everything works fine except the

I messed uo: was [math] RC2 Release Plan

Hi Phil, I discovered this morning that I messed up the bug fix, it just created another. The correct code is here under: RealMatrix getSubMatrix (int startRow, int endRow, int startColumn, int endColumn) /** * Get a submatrix. Rows and columns are indicated * counting from 0 to n-1. * *

Re: (JELLY-150) j:forEach tag not properly using varStatus attribute

you make a valid point. I had just copied that interface from the jakarta-taglibs project. It is an interface - not a class. I'll admit, I don't know too much about licensing. I was just assuming that it's legal to create a physical manifestion of interfaces defined by Sun. The actual implemen

Re: [email] Please add new build to ibiblio

On Fri, 2004-10-01 at 08:21, Martin van den Bemt wrote: > Maybe this has a better home at velocity ? Maybe, but this does seem like common practice with the email. But lets talk about this for a second. (and revisit - the plug-in adapter idea that I gracefully spoke up against earlier). F

RE: [email] Please add new build to ibiblio

Hi, >Still, adding this class to the email.jar doesn't affect the end user at >all. They can still use the email classes and jar without having >velocity on the classpath. However, if they choose to use the >VelocityEmail class they will obviously, need velocity. That's be fine by me. The doc

Re: (JELLY-150) j:forEach tag not properly using varStatus attribute

As Hans said, We don't want to introduce such a dependency in the core jelly. It used to be a problem because it wasn't maven distributable... now it looks like it actually is maven distributed (under the project-name servletapi). I'd like to have a kind of better confirmation than just seeing

RE: [email] Please add new build to ibiblio

hi, On Fri, 2004-10-01 at 08:24, Shapira, Yoav wrote: > Hi, > Hmm. Email is a simple component. If we try to make it more > complicated, we'd end up with something like [configuration] should have > had a simple, clean, fast, efficient 1.0 release ages ago but has been > adding features, refact

Re: [email] Please add new build to ibiblio

Hey... On Thu, 2004-09-30 at 19:58, Joe Germuska wrote: > At 12:54 PM -0700 9/30/04, Martin Cooper wrote: > > > Hmmm.. Personally, I don't think putting it in a different package is > >> overkill. Adding velocity requires the addition of Velocity.jar to > >> build, but not to run (unless of

[GUMP@brutus]: jakarta-commons-sandbox/commons-resources failed

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 folk at [EMAIL PROTECTED] Project commons-resources has an issue affecting its community integration. This issue affect

Re: (JELLY-150) j:forEach tag not properly using varStatus attribute

no, it belongs in javax.servlet. http://java.sun.com/products/jsp/jstl/1.1/docs/api/javax/servlet/jsp/jstl/core/LoopTagSupport.html Does your "unified format" comment pertain to the diff file I posted? This is the first patch I've ever submitted. I wasn't sure what to do with the new files, so I

DO NOT REPLY [Bug 31526] New: - Ability to add attributepackages in maven.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [jelly] running tests with using own Jelly build

FWIW I use: maven clean jar:install-snapshot -Dgoal=clean,jar:install-snapshot multiproject:goal from the top level dir (e.g. jelly). That installs jelly and then all the taglibs, testing all the way. On Mon, 04 Oct 2004 01:32:02 -0400, Hans Gilde <[EMAIL PROTECTED]> wrote: > How do I run the

Re: [jelly] running tests with using own Jelly build

do a jar:install-snapshot in the top jelly project first On Mon, 04 Oct 2004 01:32:02 -0400, Hans Gilde <[EMAIL PROTECTED]> wrote: > How do I run the tests for components in jelly-tags and force Maven to use > my build of Jelly, not the downloaded snapshot? > > thx, > > Hans > > -- http:/

[jira] Updated: (JELLY-148) Huge memory leak resulting from the use of ThreadLocal

The following issue has been updated: Updater: Guido Anzuoni (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Oct 2004 2:10 AM Comment: First, my opinions are affected by my way of dealing with templates-context-transformation in servlet env. >From my point of view, templates are in-memory

DO NOT REPLY [Bug 31515] - CLI now requires Java 1.4

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [jelly] running tests with using own Jelly build

Le 4 oct. 04, à 07:32, Hans Gilde a écrit : How do I run the tests for components in jelly-tags and force Maven to use my build of Jelly, not the downloaded snapshot? Maven has a jar-overrides feature, that should help you to make the dependency on SNAPSHOT instead of a released version using pr

DO NOT REPLY [Bug 31522] - [patch] Gamma.logGamma performance

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 31522] - [patch] Gamma.logGamma performance

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 31522] New: - [patch] Gamma.logGamma performance

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu