RE: [DISCUSS] New Expressions Sandbox Project...
Rahul Akolkar wrote: > On Thu, Apr 10, 2008 at 2:29 PM, James Carman > <[EMAIL PROTECTED]> wrote: >> On Thu, Apr 10, 2008 at 2:12 PM, Matt Benson > <[EMAIL PROTECTED]> wrote: >>> Hmm, what about "graphmacro"? Have to be careful with >>> "graph" though: without "object" it may be >>> interpreted wrongly. "beanmacro"? >>> >> >> Other interesting ideas: >> >> MethodPath - you're recording a path through objects via methods >> calls. MethodWalker - you're walking a series of method calls. >> Navigator - you're navigating through a graph of objects. >> > > > Any of these is better, IMO. Why not simply call it commons-recorder? See a "CD player" implies that your can play a CD, but a "CD recorder" implies both. Therefore commons-recorder also implies the "play" part. You use it to record an own expression/macro or you come with a ready expression/macro to play it :) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Commons Wiki] Update of "CommonsIncubatorProposal" by MattBenson
On Thu, Apr 10, 2008 at 9:20 PM, Henri Yandell <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 6:45 PM, James Carman > <[EMAIL PROTECTED]> wrote: > > Perhaps we could ask for an "Apache Commons > > Fastrack" process as part of the Incubator? > > Definitely the aim here I think. Replying to myself, very bad form. Anyway - I asked that of the Incubator and had no response, so the next step was to put together a proposal as a stronger nudge for a response. I sucked at doing that - fortunately Matt stepped up :) Incubator email: http://markmail.org/message/45ccujwi6r7fgbbh Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Commons Wiki] Update of "CommonsIncubatorProposal" by MattBenson
On Thu, Apr 10, 2008 at 6:45 PM, James Carman <[EMAIL PROTECTED]> wrote: > What would make a project become an Apache Commons Incubator "podling" > vs. an Apache Commons Sandbox project? New code -> Sandbox. Existing code outside Apache -> Incubator. > Is that something we decide on > a case-by-case basis? Perhaps we could just better formalize the > sandbox's charter so that maybe we flag projects as "donated" rather > than "grown" inside the sandbox? If a project is considered > "donated", then one of the requirements of graduation to "proper" > would be that the IP is verified. That's the other option I think we have. Have our own Incubator (or make the Sandbox to double duty) etc. > However, since the ASF has already considered this and figured out a > process for dealing with this (hence the ASF Incubator), maybe we > should ask them for a "fast-track" or "lite" process for bringing code > in from the outside. Perhaps there could be a process whereby we > figure out if the IP restrictions are okay somewhat quickly, but the > community isn't necessarily in place (I think that is primarily the > other restriction)? We do want some community checking though. CSV is my example of something that should have gone through the Incubator. The donators should have been able to get ASF committership while it was in the Incubator and there would have been a small level of community building focus. It didn't fit the sandbox well because it was a largely finished component and the sandbox is all about developing or assembling new code currently. > Perhaps we could ask for an "Apache Commons > Fastrack" process as part of the Incubator? Definitely the aim here I think. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j2me commons?
Selon Rahul Akolkar <[EMAIL PROTECTED]>: > I suggest we let Nick have a go at it. +1 Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Commons Wiki] Update of "CommonsIncubatorProposal" by MattBenson
What would make a project become an Apache Commons Incubator "podling" vs. an Apache Commons Sandbox project? Is that something we decide on a case-by-case basis? Perhaps we could just better formalize the sandbox's charter so that maybe we flag projects as "donated" rather than "grown" inside the sandbox? If a project is considered "donated", then one of the requirements of graduation to "proper" would be that the IP is verified. However, since the ASF has already considered this and figured out a process for dealing with this (hence the ASF Incubator), maybe we should ask them for a "fast-track" or "lite" process for bringing code in from the outside. Perhaps there could be a process whereby we figure out if the IP restrictions are okay somewhat quickly, but the community isn't necessarily in place (I think that is primarily the other restriction)? Perhaps we could ask for an "Apache Commons Fastrack" process as part of the Incubator? On Thu, Apr 10, 2008 at 6:58 PM, Apache Wiki <[EMAIL PROTECTED]> wrote: > Dear Wiki user, > > You have subscribed to a wiki page or wiki category on "Commons Wiki" for > change notification. > > The following page has been changed by MattBenson: > http://wiki.apache.org/commons/CommonsIncubatorProposal > > The comment on the change is: > Initial proposal for a Commons Incubator > > New page: > Commons Incubator Proposal > > ABSTRACT > > The Commons Incubator would act as a "perpetual podling" or "mini-Incubator" > overseeing the influx of components to be adopted into Apache Commons. > > > BACKGROUND > > Apache Commons, a conglomerate of smallish Java libraries, lacks a good > procedure > for importing preexisting codebases. > > > RATIONALE > > The typical ASF top-level project (TLP) absorbs code donations by means of a > software grant. > Clearly delineated subprojects (usually partially or completely dependent on > the TLP) often > enter instead through the Incubator. Commons, as a project that has no code > other than that > of its subprojects, is essentially a microcosm of the ASF itself. Commons > has long offered a > sandbox area for the development of new ideas, similar to the approach now > taken in Apache Labs. > With regard to the creation of new subprojects from preexisting codebases, > however, the PMC is > in agreement that procedures similar to those in practice in the ASF > Incubator are more appropriate > than the software grant approach, given that the Incubator has already > formalized much the same > process as would need to be taken to guarantee the acceptability of donated > code. Unfortunately > the processes of the Incubator proper are not a perfect fit. > > With regard to community exit requirements, a typical podling requires a > heterogenous community > of three or more developers. Commons considers itself an open community in > that all Commons > committers have karma to all components, thus any component to graduate into > Commons proper > inherits an existing, diverse community. This greatly mitigates any > component's risk of orphanhood. > The PMC envisions Commons' incubator space as functioning in a manner > similar to that in which its > development sandbox currently operates: all ASF committers are welcome to > participate in the > Commons sandbox, and would be welcome to contribute to incubating > components, subject to a natural > consensus-building process. Active contributors to graduating components > would be accepted into > the project as full Commons committers with shared karma. > > Another aspect in which existing Incubator practices are suboptimal for > Commons' requirements is > that, a Commons component being a relatively small entity, it is difficult > to justify expending the > same effort to set one up as would typically be required for a normal-sized > podling. Commons > expects this situation would be compounded by the large number of components > currently slated for > incubation. It would be seen as advantageous to keep incubating Commons > components under a > single Subversion tree, and as subcomponents of a single JIRA project. > Finally, the existing > Commons communications lists could be utilized. Component setup would thus > be minimal. > > Having established that setting up a Commons Incubator separate from the > Apache Incubator would > be counterproductive and quite a duplication of effort, Commons would like > to see established on its > behalf a "special case" podling or miniature Incubator whose exit criteria > parallel those Commons > uses to gauge the propriety of a sandbox component's promotion to "proper" > status, namely: > > * The component is ready for its first ASF release. > * At least three people are available for development/maintenance. > * All Incubator legal checks have been passed. > > > INITIAL GOALS > > Prove/hone the Commons Incubator approach on several candidates that have > been propose
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 8:28 PM, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > The first-class Expression object encapsulates the specifics of the > > implementation (whether it be a String or some Serializable object or > > whatever). This way, you just code to the commons-expression API > > (getValue/setValue) rather than carrying around some string. Also, > > the implementations are free to "compile" their expressions so that > > they perform better (the MVEL implementation does this and it smokes > > all of the others in my simple benchmarking, because I can't get OGNL > > to compile its expression without a "root object" from the beginning). > > > > > Makes sense, its worthwhile to have an opportunity to store compiled forms. > > I was just looking at the OGNL API, I'm not sure about the root object > either. > I really think being able to encapsulate these ideas is beneficial (and makes this stuff more reusable). Of course, allowing these things to be serialized is important too (for web components that need to be stored in the HTTP session such as in Wicket for example). I pinged Jesse Kuhnert today to ask him about it (the current API). He confirmed that it's not currently supported, but I asked if it could be. > > If people feel that [expression] isn't the right name for what I've > > come up with, I don't really care (as I said, what's in a name). But, > > the idea of an expression just fit in my mind. I'll try to come up > > with something else if you're really that opposed to me using the name > > "expression". The term "macro" came to mind when I was thinking about > > a name for this thing, since the builders are essentially recording > > something from the user (on a proxy) that will later be played back > > (on some other object). > > > > > Yup, and [expression] doesn't convey that IMO. Thanks for being open > to finding an alternative name. > No problem at all! As I've said before, I'm not all about the name and I agree with you that I don't necessarily want to tie up a name like "expression" since it could be used for a library which provides a more complete abstraction of expression languages. This is somewhat like picking a keyword for a programming language. We have to be careful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 2:29 PM, James Carman <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 2:12 PM, Matt Benson <[EMAIL PROTECTED]> wrote: > > Hmm, what about "graphmacro"? Have to be careful with > > "graph" though: without "object" it may be > > interpreted wrongly. "beanmacro"? > > > > Other interesting ideas: > > MethodPath - you're recording a path through objects via methods calls. > MethodWalker - you're walking a series of method calls. > Navigator - you're navigating through a graph of objects. > Any of these is better, IMO. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j2me commons?
No :) [Damn.. I have to justify that? What happened to "Because I said so" "Because it's hot and will hurt" gah] Jakarta's on the way out as it's a disjoint umbrella. Commons is a joint umbrella [erm... maybe I can't abuse English that way... overlapping umbrella] and is the way of the future(tm). Hen On Thu, Apr 10, 2008 at 1:03 PM, James Carman <[EMAIL PROTECTED]> wrote: > How about this goes into Jakarta? > > > > > > On 4/10/08, Henri Yandell <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 10, 2008 at 9:35 AM, Rahul Akolkar <[EMAIL PROTECTED]> > > wrote: > > > On Thu, Apr 10, 2008 at 10:00 AM, Nick Burch <[EMAIL PROTECTED]> wrote: > > > > > > > Hi All > > > > > > > > I've been chatting to a few people at ApacheCon about a j2me commons, > > and > > > > they suggested I bring the idea to the dev list. > > > > > > > > > > > > > I'm one of those people. > > > > > > > > > > > > > My idea was to have a commons library that implemented all the common > > > > things you want to do for j2me, which have annoyingly been missed out > > of > > > > the j2me spec, or are quite hard to do. > > > > > > > > Currently, I have a few functions that I've written for a project, > > which > > > > I'm happy to apache license. What I also have is tests for them, and > > some > > > > ant magic which allows you to build them on j2se, and also to unit > test > > > > them on j2se, against a j2me class library (assuming you have the sun > > wtk > > > > installed somewhere) > > > > > > > > > > > > Do people think this is worth putting in as a new sandbox component? > > I'm > > > > happy to oversee the new component, if people are happy for me to put > > it > > > > in (+grant myself appropriate svn karma to do so) > > > > > > > > > > > > > I think we need a different name ( not [j2me] ). Please try to define > > > a scope via a proposal ( see recent example: > > > http://markmail.org/message/4z6z4zendcusdcnu ) -- its great for > > > archival so I like those things :-) > > > > > > All - > > > > > > I suggest we let Nick have a go at it. > > > > > > The scope / component size question raised is real. I think we will > > > have a better idea when we see the code. > > > > +1, good thinking. If things scope grows too large, they can always go > > upwards. It's much harder for an Incubator project or TLP to discover > > it was in fact too small and go downwards. As Nick's a committer, > > let's give him Sandbox space. > > > > Hen > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 1:46 PM, James Carman <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 12:12 PM, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > > I don't know about this API. The idea behind [expression] is that > > > it's not necessarily string-based (a lot of the impls are, but the > > > Javassist one wouldn't be; it'll probably only be available via > > > builder). The [expression] project strives to treat the expression as > > > a first-class object which encapsulates the underlying technology. > > > > > > > > > Since most impls are (they generate their own parse trees etc.) and > > any intermediate "first-class object" simply gets in the way IMO. > > > > > > The first-class Expression object encapsulates the specifics of the > implementation (whether it be a String or some Serializable object or > whatever). This way, you just code to the commons-expression API > (getValue/setValue) rather than carrying around some string. Also, > the implementations are free to "compile" their expressions so that > they perform better (the MVEL implementation does this and it smokes > all of the others in my simple benchmarking, because I can't get OGNL > to compile its expression without a "root object" from the beginning). > Makes sense, its worthwhile to have an opportunity to store compiled forms. I was just looking at the OGNL API, I'm not sure about the root object either. > > > > > > I can put my existing code into the sandbox to bootstrap it. I have > > > access to the sandbox. I just wanted to make sure nobody completely > > > objected to the idea behind [expression] with respect to the commons > > > in general. > > > > > > > > > I think we may have sufficiently different ideas on what we need to > > begin playing in different sandboxes. > > > > That also means we need two component names. I do think the name > > [expression] would be misleading for the idea you've proposed. In > > fact, thats what got me thinking we wanted similar things :-) Any > > alternatives I could think of suggesting were a bit long for my taste, > > I'll keep trying. I'd like to use the [expression] for the > > Context+Evaluator API, which is quite a common theme in many first > > class expression language impls. > > If people feel that [expression] isn't the right name for what I've > come up with, I don't really care (as I said, what's in a name). But, > the idea of an expression just fit in my mind. I'll try to come up > with something else if you're really that opposed to me using the name > "expression". The term "macro" came to mind when I was thinking about > a name for this thing, since the builders are essentially recording > something from the user (on a proxy) that will later be played back > (on some other object). > Yup, and [expression] doesn't convey that IMO. Thanks for being open to finding an alternative name. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum] BUILD FAILURE: Commons IO
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=75628&projectId=155
Build statistics:
State: Failed
Previous State: Ok
Started at: Thu 10 Apr 2008 16:52:41 -0700
Finished at: Thu 10 Apr 2008 16:54:00 -0700
Total time: 1m 18s
Build Trigger: Schedule
Build Number: 75
Exit code: 1
Building machine hostname: vmbuild.apache.org
Operating system : Linux(unknown)
Java Home version :
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)
Builder version :
Maven version: 2.0.7
Java version: 1.5.0_12
OS name: "linux" version: "2.6.20-16-server" arch: "i386"
SCM Changes:
Changed: niallp @ Thu 10 Apr 2008 16:06:38 -0700
Comment: IO-163 Change FileUtils.toURLs() to use File.toURI().toURL() rather
than File.toURL() - thanks to Alex Miller for the suggestion
Files changed:
/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java (
647000 )
/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsTestCase.java
( 647000 )
Dependencies Changes:
No dependencies changed
Build Defintion:
POM filename: pom.xml
Goals: clean deploy
Arguments: --batch-mode -DaltDeploymentRepository=vmbuild.repo::default::file://localhost/home/continuum/data/commons -Pci
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Java 5
Description:
Test Summary:
Tests: 500
Failures: 2
Total time: 31541
Output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Commons IO
[INFO]task-segment: [clean, deploy]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /home/continuum/data/working-directory/155/target
[INFO] Deleting directory
/home/continuum/data/working-directory/155/target/classes
[INFO] Deleting directory
/home/continuum/data/working-directory/155/target/test-classes
[INFO] Deleting directory /home/continuum/data/working-directory/155/target/site
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
[copy] Copying 2 files to
/home/continuum/data/working-directory/155/target/apidocs/META-INF
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 78 source files to
/home/continuum/data/working-directory/155/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 67 source files to
/home/continuum/data/working-directory/155/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/continuum/data/working-directory/155/target/surefire-reports
---
T E S T S
---
Running org.apache.commons.io.output.NullWriterTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec
Running org.apache.commons.io.output.ClosedOutputStreamTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.commons.io.FilenameUtilsTestCase
Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.462 sec
Running org.apache.commons.io.CopyUtilsTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec
Running org.apache.commons.io.output.FileWriterWithEncodingTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.491 sec
Running org.apache.commons.io.LineIteratorTestCase
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.052 sec
Running org.apache.commons.io.FileUtilsWaitForTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.852 sec
Running org.apache.commons.io.filefilter.RegexFileFilterTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.commons.io.FileUtilsTes
[continuum] BUILD FAILURE: Commons IO
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=75628&projectId=155
Build statistics:
State: Failed
Previous State: Ok
Started at: Thu 10 Apr 2008 16:52:41 -0700
Finished at: Thu 10 Apr 2008 16:54:00 -0700
Total time: 1m 18s
Build Trigger: Schedule
Build Number: 75
Exit code: 1
Building machine hostname: vmbuild.apache.org
Operating system : Linux(unknown)
Java Home version :
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)
Builder version :
Maven version: 2.0.7
Java version: 1.5.0_12
OS name: "linux" version: "2.6.20-16-server" arch: "i386"
SCM Changes:
Changed: niallp @ Thu 10 Apr 2008 16:06:38 -0700
Comment: IO-163 Change FileUtils.toURLs() to use File.toURI().toURL() rather
than File.toURL() - thanks to Alex Miller for the suggestion
Files changed:
/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java (
647000 )
/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsTestCase.java
( 647000 )
Dependencies Changes:
No dependencies changed
Build Defintion:
POM filename: pom.xml
Goals: clean deploy
Arguments: --batch-mode -DaltDeploymentRepository=vmbuild.repo::default::file://localhost/home/continuum/data/commons -Pci
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Java 5
Description:
Test Summary:
Tests: 500
Failures: 2
Total time: 31541
Output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Commons IO
[INFO]task-segment: [clean, deploy]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /home/continuum/data/working-directory/155/target
[INFO] Deleting directory
/home/continuum/data/working-directory/155/target/classes
[INFO] Deleting directory
/home/continuum/data/working-directory/155/target/test-classes
[INFO] Deleting directory /home/continuum/data/working-directory/155/target/site
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
[copy] Copying 2 files to
/home/continuum/data/working-directory/155/target/apidocs/META-INF
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 78 source files to
/home/continuum/data/working-directory/155/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 67 source files to
/home/continuum/data/working-directory/155/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/continuum/data/working-directory/155/target/surefire-reports
---
T E S T S
---
Running org.apache.commons.io.output.NullWriterTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec
Running org.apache.commons.io.output.ClosedOutputStreamTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.commons.io.FilenameUtilsTestCase
Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.462 sec
Running org.apache.commons.io.CopyUtilsTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec
Running org.apache.commons.io.output.FileWriterWithEncodingTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.491 sec
Running org.apache.commons.io.LineIteratorTestCase
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.052 sec
Running org.apache.commons.io.FileUtilsWaitForTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.852 sec
Running org.apache.commons.io.filefilter.RegexFileFilterTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.commons.io.FileUtilsTes
Re: [Commons Wiki] Update of "CommonsIncubatorProposal" by MattBenson
Feedback sought! -Matt --- Apache Wiki <[EMAIL PROTECTED]> wrote: > Dear Wiki user, > > You have subscribed to a wiki page or wiki category > on "Commons Wiki" for change notification. > > The following page has been changed by MattBenson: > http://wiki.apache.org/commons/CommonsIncubatorProposal > > The comment on the change is: > Initial proposal for a Commons Incubator > > New page: > Commons Incubator Proposal > > ABSTRACT > > The Commons Incubator would act as a "perpetual > podling" or "mini-Incubator" > overseeing the influx of components to be adopted > into Apache Commons. > > > BACKGROUND > > Apache Commons, a conglomerate of smallish Java > libraries, lacks a good procedure > for importing preexisting codebases. > > > RATIONALE > > The typical ASF top-level project (TLP) absorbs code > donations by means of a software grant. > Clearly delineated subprojects (usually partially or > completely dependent on the TLP) often > enter instead through the Incubator. Commons, as a > project that has no code other than that > of its subprojects, is essentially a microcosm of > the ASF itself. Commons has long offered a > sandbox area for the development of new ideas, > similar to the approach now taken in Apache Labs. > With regard to the creation of new subprojects from > preexisting codebases, however, the PMC is > in agreement that procedures similar to those in > practice in the ASF Incubator are more appropriate > than the software grant approach, given that the > Incubator has already formalized much the same > process as would need to be taken to guarantee the > acceptability of donated code. Unfortunately > the processes of the Incubator proper are not a > perfect fit. > > With regard to community exit requirements, a > typical podling requires a heterogenous community > of three or more developers. Commons considers > itself an open community in that all Commons > committers have karma to all components, thus any > component to graduate into Commons proper > inherits an existing, diverse community. This > greatly mitigates any component's risk of > orphanhood. > The PMC envisions Commons' incubator space as > functioning in a manner similar to that in which its > development sandbox currently operates: all ASF > committers are welcome to participate in the > Commons sandbox, and would be welcome to contribute > to incubating components, subject to a natural > consensus-building process. Active contributors to > graduating components would be accepted into > the project as full Commons committers with shared > karma. > > Another aspect in which existing Incubator practices > are suboptimal for Commons' requirements is > that, a Commons component being a relatively small > entity, it is difficult to justify expending the > same effort to set one up as would typically be > required for a normal-sized podling. Commons > expects this situation would be compounded by the > large number of components currently slated for > incubation. It would be seen as advantageous to > keep incubating Commons components under a > single Subversion tree, and as subcomponents of a > single JIRA project. Finally, the existing > Commons communications lists could be utilized. > Component setup would thus be minimal. > > Having established that setting up a Commons > Incubator separate from the Apache Incubator would > be counterproductive and quite a duplication of > effort, Commons would like to see established on its > behalf a "special case" podling or miniature > Incubator whose exit criteria parallel those Commons > uses to gauge the propriety of a sandbox component's > promotion to "proper" status, namely: > > * The component is ready for its first ASF release. > * At least three people are available for > development/maintenance. > * All Incubator legal checks have been passed. > > > INITIAL GOALS > > Prove/hone the Commons Incubator approach on > several candidates that have been proposed as > new Apache Commons subprojects, and for which a > PMC vote indicates willingness to incubate. > > > CURRENT STATUS > > (Applicable at incubating component level) > > Meritocracy: > > Community: > > Core Developers: > > Alignment: > > > KNOWN RISKS > > (Applicable at incubating component level) > > Orphaned Products: > > Inexperience with Open Source: > > Homogenous Developers: > > Reliance on Salaried Developers: > > No Ties to Other Apache Products: > > A Fascination with the Apache Brand: > > > DOCUMENTATION > > (Applicable at incubating component level) > > > INITIAL SOURCE > > (Applicable at incubating component level) > > > EXTERNAL DEPENDENCIES > Optimally any non-optional dependencies for > Commons components will be other Commons > components. Failing that, normal ASF third-party > licensing policies to be enforced. > > > REQUIRED RESOURCES > > Mailing Lists: > Commons lists > > Subversion Directory: > Single Subversion tree under In
[Commons Wiki] Update of "CommonsIncubatorProposal" by MattBenson
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The following page has been changed by MattBenson: http://wiki.apache.org/commons/CommonsIncubatorProposal The comment on the change is: Initial proposal for a Commons Incubator New page: Commons Incubator Proposal ABSTRACT The Commons Incubator would act as a "perpetual podling" or "mini-Incubator" overseeing the influx of components to be adopted into Apache Commons. BACKGROUND Apache Commons, a conglomerate of smallish Java libraries, lacks a good procedure for importing preexisting codebases. RATIONALE The typical ASF top-level project (TLP) absorbs code donations by means of a software grant. Clearly delineated subprojects (usually partially or completely dependent on the TLP) often enter instead through the Incubator. Commons, as a project that has no code other than that of its subprojects, is essentially a microcosm of the ASF itself. Commons has long offered a sandbox area for the development of new ideas, similar to the approach now taken in Apache Labs. With regard to the creation of new subprojects from preexisting codebases, however, the PMC is in agreement that procedures similar to those in practice in the ASF Incubator are more appropriate than the software grant approach, given that the Incubator has already formalized much the same process as would need to be taken to guarantee the acceptability of donated code. Unfortunately the processes of the Incubator proper are not a perfect fit. With regard to community exit requirements, a typical podling requires a heterogenous community of three or more developers. Commons considers itself an open community in that all Commons committers have karma to all components, thus any component to graduate into Commons proper inherits an existing, diverse community. This greatly mitigates any component's risk of orphanhood. The PMC envisions Commons' incubator space as functioning in a manner similar to that in which its development sandbox currently operates: all ASF committers are welcome to participate in the Commons sandbox, and would be welcome to contribute to incubating components, subject to a natural consensus-building process. Active contributors to graduating components would be accepted into the project as full Commons committers with shared karma. Another aspect in which existing Incubator practices are suboptimal for Commons' requirements is that, a Commons component being a relatively small entity, it is difficult to justify expending the same effort to set one up as would typically be required for a normal-sized podling. Commons expects this situation would be compounded by the large number of components currently slated for incubation. It would be seen as advantageous to keep incubating Commons components under a single Subversion tree, and as subcomponents of a single JIRA project. Finally, the existing Commons communications lists could be utilized. Component setup would thus be minimal. Having established that setting up a Commons Incubator separate from the Apache Incubator would be counterproductive and quite a duplication of effort, Commons would like to see established on its behalf a "special case" podling or miniature Incubator whose exit criteria parallel those Commons uses to gauge the propriety of a sandbox component's promotion to "proper" status, namely: * The component is ready for its first ASF release. * At least three people are available for development/maintenance. * All Incubator legal checks have been passed. INITIAL GOALS Prove/hone the Commons Incubator approach on several candidates that have been proposed as new Apache Commons subprojects, and for which a PMC vote indicates willingness to incubate. CURRENT STATUS (Applicable at incubating component level) Meritocracy: Community: Core Developers: Alignment: KNOWN RISKS (Applicable at incubating component level) Orphaned Products: Inexperience with Open Source: Homogenous Developers: Reliance on Salaried Developers: No Ties to Other Apache Products: A Fascination with the Apache Brand: DOCUMENTATION (Applicable at incubating component level) INITIAL SOURCE (Applicable at incubating component level) EXTERNAL DEPENDENCIES Optimally any non-optional dependencies for Commons components will be other Commons components. Failing that, normal ASF third-party licensing policies to be enforced. REQUIRED RESOURCES Mailing Lists: Commons lists Subversion Directory: Single Subversion tree under Incubator or Commons Issue Tracking: A single JIRA project with subcomponents to be managed by Mentors INITIAL COMMITTERS (Applicable at incubating component level) AFFILIATIONS (Applicable at incubating component level) SPONSORS Champion: Henri Yandell (or I will champion if you're going to be too busy -MJB) Nominated Mentors: Henri Yandell,
Re: j2me commons?
On Thu, Apr 10, 2008 at 3:23 PM, Henri Yandell <[EMAIL PROTECTED]> wrote: > +1, good thinking. If things scope grows too large, they can always go > upwards. It's much harder for an Incubator project or TLP to discover > it was in fact too small and go downwards. As Nick's a committer, > let's give him Sandbox space. I guess there's no rule that says that a commons project can't itself have subprojects, so I guess it could get split that way and just stay in commons (it doesn't have to become a TLP necessarily, but it probably would if it got too big). I'm +1 for sandboxing it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j2me commons?
On Thu, Apr 10, 2008 at 8:23 PM, Henri Yandell <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 10, 2008 at 9:35 AM, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 10, 2008 at 10:00 AM, Nick Burch <[EMAIL PROTECTED]> wrote: > > > > > Hi All > > > > > > I've been chatting to a few people at ApacheCon about a j2me commons, > and > > > they suggested I bring the idea to the dev list. > > > > > > > > > I'm one of those people. > > > > > > > > > My idea was to have a commons library that implemented all the common > > > things you want to do for j2me, which have annoyingly been missed out of > > > the j2me spec, or are quite hard to do. > > > > > > Currently, I have a few functions that I've written for a project, which > > > I'm happy to apache license. What I also have is tests for them, and > some > > > ant magic which allows you to build them on j2se, and also to unit test > > > them on j2se, against a j2me class library (assuming you have the sun > wtk > > > installed somewhere) > > > > > > > > > Do people think this is worth putting in as a new sandbox component? I'm > > > happy to oversee the new component, if people are happy for me to put it > > > in (+grant myself appropriate svn karma to do so) > > > > > > > > > I think we need a different name ( not [j2me] ). Please try to define > > a scope via a proposal ( see recent example: > > http://markmail.org/message/4z6z4zendcusdcnu ) -- its great for > > archival so I like those things :-) > > > > All - > > > > I suggest we let Nick have a go at it. > > > > The scope / component size question raised is real. I think we will > > have a better idea when we see the code. > > +1, good thinking. If things scope grows too large, they can always go > upwards. It's much harder for an Incubator project or TLP to discover > it was in fact too small and go downwards. As Nick's a committer, > let's give him Sandbox space. No problem from me doing this in the sandbox and seeing how it works out. Niall > Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j2me commons?
How about this goes into Jakarta? On 4/10/08, Henri Yandell <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 9:35 AM, Rahul Akolkar <[EMAIL PROTECTED]> > wrote: > > On Thu, Apr 10, 2008 at 10:00 AM, Nick Burch <[EMAIL PROTECTED]> wrote: > > > > > Hi All > > > > > > I've been chatting to a few people at ApacheCon about a j2me commons, > and > > > they suggested I bring the idea to the dev list. > > > > > > > > > I'm one of those people. > > > > > > > > > My idea was to have a commons library that implemented all the common > > > things you want to do for j2me, which have annoyingly been missed out > of > > > the j2me spec, or are quite hard to do. > > > > > > Currently, I have a few functions that I've written for a project, > which > > > I'm happy to apache license. What I also have is tests for them, and > some > > > ant magic which allows you to build them on j2se, and also to unit test > > > them on j2se, against a j2me class library (assuming you have the sun > wtk > > > installed somewhere) > > > > > > > > > Do people think this is worth putting in as a new sandbox component? > I'm > > > happy to oversee the new component, if people are happy for me to put > it > > > in (+grant myself appropriate svn karma to do so) > > > > > > > > > I think we need a different name ( not [j2me] ). Please try to define > > a scope via a proposal ( see recent example: > > http://markmail.org/message/4z6z4zendcusdcnu ) -- its great for > > archival so I like those things :-) > > > > All - > > > > I suggest we let Nick have a go at it. > > > > The scope / component size question raised is real. I think we will > > have a better idea when we see the code. > > +1, good thinking. If things scope grows too large, they can always go > upwards. It's much harder for an Incubator project or TLP to discover > it was in fact too small and go downwards. As Nick's a committer, > let's give him Sandbox space. > > Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j2me commons?
On Thu, Apr 10, 2008 at 9:35 AM, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 10:00 AM, Nick Burch <[EMAIL PROTECTED]> wrote: > > > Hi All > > > > I've been chatting to a few people at ApacheCon about a j2me commons, and > > they suggested I bring the idea to the dev list. > > > > > I'm one of those people. > > > > > My idea was to have a commons library that implemented all the common > > things you want to do for j2me, which have annoyingly been missed out of > > the j2me spec, or are quite hard to do. > > > > Currently, I have a few functions that I've written for a project, which > > I'm happy to apache license. What I also have is tests for them, and some > > ant magic which allows you to build them on j2se, and also to unit test > > them on j2se, against a j2me class library (assuming you have the sun wtk > > installed somewhere) > > > > > > Do people think this is worth putting in as a new sandbox component? I'm > > happy to oversee the new component, if people are happy for me to put it > > in (+grant myself appropriate svn karma to do so) > > > > > I think we need a different name ( not [j2me] ). Please try to define > a scope via a proposal ( see recent example: > http://markmail.org/message/4z6z4zendcusdcnu ) -- its great for > archival so I like those things :-) > > All - > > I suggest we let Nick have a go at it. > > The scope / component size question raised is real. I think we will > have a better idea when we see the code. +1, good thinking. If things scope grows too large, they can always go upwards. It's much harder for an Incubator project or TLP to discover it was in fact too small and go downwards. As Nick's a committer, let's give him Sandbox space. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum] BUILD SUCCESSFUL: Commons Monitoring (Sandbox)
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=75547&projectId=538
Build statistics:
State: Ok
Previous State: Failed
Started at: Thu 10 Apr 2008 12:08:25 -0700
Finished at: Thu 10 Apr 2008 12:08:57 -0700
Total time: 32s
Build Trigger: Schedule
Build Number: 5
Exit code: 0
Building machine hostname: vmbuild.apache.org
Operating system : Linux(unknown)
Java Home version :
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)
Builder version :
Maven version: 2.0.7
Java version: 1.5.0_12
OS name: "linux" version: "2.6.20-16-server" arch: "i386"
SCM Changes:
Changed: nicolas @ Thu 10 Apr 2008 08:34:13 -0700
Comment: fix test
Files changed:
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/FlotRenderer.java
( 646846 )
Dependencies Changes:
No dependencies changed
Build Defintion:
POM filename: pom.xml
Goals: clean deploy
Arguments: --batch-mode -DaltDeploymentRepository=vmbuild.repo::default::file://localhost/home/continuum/data/commons -Pci
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Java 5
Description:
Test Summary:
Tests: 27
Failures: 0
Total time: 2651
Output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Commons Monitoring (Sandbox)
[INFO]task-segment: [clean, deploy]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /home/continuum/data/working-directory/538/target
[INFO] Deleting directory
/home/continuum/data/working-directory/538/target/classes
[INFO] Deleting directory
/home/continuum/data/working-directory/538/target/test-classes
[INFO] Deleting directory /home/continuum/data/working-directory/538/target/site
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
[copy] Copying 2 files to
/home/continuum/data/working-directory/538/target/apidocs/META-INF
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 62 source files to
/home/continuum/data/working-directory/538/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 12 source files to
/home/continuum/data/working-directory/538/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/continuum/data/working-directory/538/target/surefire-reports
---
T E S T S
---
Running org.apache.commons.monitoring.impl.DefaultRepositoryTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.071 sec
Running org.apache.commons.monitoring.impl.ThreadSafeCounterTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
Running org.apache.commons.monitoring.UnitTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Running org.apache.commons.monitoring.StopWatchTest
paused after 1ns
running for 1ns
stoped after 2ns
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
Running org.apache.commons.monitoring.MonitoringTest
50 executions took 2463547000ns
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.476 sec
Running org.apache.commons.monitoring.listener.SecondaryReposioryTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running org.apache.commons.monitoring.ExecutionStackTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.commons.monitoring.impl.CompositeValuesMonitorTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.commons.monitoring.reporting.SelectorTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec
Runni
Re: svn commit: r646903 - /commons/sandbox/exec/trunk/src/site/xdoc/testmatrix.xml
On 10/04/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: sgoeschl > Date: Thu Apr 10 11:02:21 2008 > New Revision: 646903 > > URL: http://svn.apache.org/viewvc?rev=646903&view=rev > Log: > Adding a page to collect the sucesses/failures for various operating systems > and jvm versions > > Added: > commons/sandbox/exec/trunk/src/site/xdoc/testmatrix.xml > > Added: commons/sandbox/exec/trunk/src/site/xdoc/testmatrix.xml Needs svn:eol-style native please ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r646842 - /commons/sandbox/exec/trunk/src/test/scripts/forever.sh
On 10/04/2008, Siegfried Goeschl <[EMAIL PROTECTED]> wrote: > Hi Sebb, > > > > But that does not work on e.g. FreeBSD. > > > > Indeed the code will now just create an ever-larger file, not print > > ... to the screen > > > > +) printing the funny dots was just something I ommited to delete - I want > to make a verification to ensure that the script was executed successfully > by ensure that the file exists and is not empty In that case, use > rather than >> (and document what the purpose is) > +) would the statement would work on FreeBSD in general? AFAIK echo '.\c' "works" on any Un*x, as does echo -n . in the sense that something will be printed. However some OSes (e.g. HP-UX) use the first format to suppress the EOL, most use the second format. I don't know how to differentiate them (other than adding a test before the loop) Is it important that the output file is updated every second? > Cheers, > > Siegfried Goeschl > > sebb wrote: > > > > > On 10/04/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > Author: sgoeschl > > > Date: Thu Apr 10 08:22:17 2008 > > > New Revision: 646842 > > > > > > URL: http://svn.apache.org/viewvc?rev=646842&view=rev > > > Log: > > > Changed the usage of the echo statement to work with HP-UX (thanks to > sebb) > > > > > > Modified: > > > > commons/sandbox/exec/trunk/src/test/scripts/forever.sh > > > > > > Modified: > commons/sandbox/exec/trunk/src/test/scripts/forever.sh > > > URL: > http://svn.apache.org/viewvc/commons/sandbox/exec/trunk/src/test/scripts/forever.sh?rev=646842&r1=646841&r2=646842&view=diff > > > > == > > > --- > commons/sandbox/exec/trunk/src/test/scripts/forever.sh > (original) > > > +++ > commons/sandbox/exec/trunk/src/test/scripts/forever.sh Thu > Apr 10 08:22:17 2008 > > > @@ -22,6 +22,5 @@ > > > while test "notempty" > > > do > > > sleep 1 > > > - echo -n . > > > - # echo -n . >> ./target/forever.txt > > > + echo '.\c' >> ./target/forever.txt > > > > > > > > > > But that does not work on e.g. FreeBSD. > > > > Indeed the code will now just create an ever-larger file, not print > > ... to the screen > > > > > > > > > done > > > > > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 2:12 PM, Matt Benson <[EMAIL PROTECTED]> wrote: > Hmm, what about "graphmacro"? Have to be careful with > "graph" though: without "object" it may be > interpreted wrongly. "beanmacro"? > Other interesting ideas: MethodPath - you're recording a path through objects via methods calls. MethodWalker - you're walking a series of method calls. Navigator - you're navigating through a graph of objects. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 2:10 PM, Matt Benson <[EMAIL PROTECTED]> wrote: > Without having looked at the code, I'm not > understanding why [proxy] would be a "first-class" > dependency. Seems like it would be optional depending > on whether a client of [expression?] wanted to use the > recording implementation. > Proxy isn't a required dependency. You could use the existing Expression implementations without having to record them. However, the recording feature is what makes this library so cool, IMHO. Recording gives you the following benefits: - You're using Java syntax to record what you want. - If you change method names, you'll either get a compiler error on your recording code or the refactoring utility will change it for you. - Less error-prone. If you can traverse the object graph in Java, the builder can make an expression that can do it (aside from indexing into arrays or using fields of course). > I still agree with Rahul that object graph navigation > is the commonality here. Oooh, what about commons-navigator? > But once you remove the > concept of an integral String representation it seems > like generic functor stuff to me. JXPath has Pointers > that behave somewhat like what you're suggesting, > James, but ultimately they are still tied to the > original syntactic representation. Of course, "object > graph navigation" is 3/4 of OGNL's name, isn't it? > Once you turn the originating syntactic representation into an Expression object, you're free to do with it what you want. The syntax is hidden behind the Expression. So, other libraries that take Expression objects (like the one I'm going to help write for Wicket) don't have to have any idea that you're using a String behind the scenes (or possibly nothing but a hard-wired class that does exactly what you did in the first place). > I MIGHT be able to accept the recording implementation > as an "expression" if you at least made the toString() > of the recording present something expressionlike: > e.g. > > record < > getFoo() > getBar() > getBaz() > > > toString(): "getFoo().getBar().getBaz()" > That would be easy to do, really. All of the recorders currently use Proxy's idea of an InvocationRecorder which gives you a list of RecordedInvocations. It'd be trivial to write a toString() method somewhere that took the method names and made a string like that out of them (along with the parameters used along the way too). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
Hmm, what about "graphmacro"? Have to be careful with
"graph" though: without "object" it may be
interpreted wrongly. "beanmacro"?
-Matt
--- James Carman <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 10, 2008 at 1:59 PM, James Carman
> <[EMAIL PROTECTED]> wrote:
> > On Thu, Apr 10, 2008 at 1:46 PM, James Carman
> > <[EMAIL PROTECTED]> wrote:
> > > If people feel that [expression] isn't the
> right name for what I've
> > > come up with, I don't really care (as I said,
> what's in a name). But,
> > > the idea of an expression just fit in my mind.
> I'll try to come up
> > > with something else if you're really that
> opposed to me using the name
> > > "expression". The term "macro" came to mind
> when I was thinking about
> > > a name for this thing, since the builders are
> essentially recording
> > > something from the user (on a proxy) that will
> later be played back
> > > (on some other object).
> > >
> >
> > Other words that convey a similar idea:
> >
> > variable - the "expression" is really a variable
> (a value that can be
> > modified or retrieved).
> > value - the "expression" represents a
> settable/gettable "value"
> > shortcut - the "expression" is a shortcut for
> calling a (potentially)
> > chained series of method calls
> > flatten - the "expression" flattens the chained
> series of method calls
> >
>
> To spell out the "macro" API, it would be:
>
> public interface Macro
> {
> public V getValue(R root);
> public void setValue(R root, V value);
> }
>
> public interface Recorder
> {
> public R template();
> public Macro record(V value);
> }
>
> A usage would look like:
>
> Recorder recorder = ...;
> Macro addressCityMacro =
>
recorder.record(recorder.template().getAddress().getCity());
> Person p = ...;
> String city = addressCityMacro.getValue(p);
>
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
--- James Carman <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 12:12 PM, Rahul Akolkar > <[EMAIL PROTECTED]> wrote: > > > > I don't know about this API. The idea behind > [expression] is that > > > it's not necessarily string-based (a lot of the > impls are, but the > > > Javassist one wouldn't be; it'll probably only > be available via > > > builder). The [expression] project strives to > treat the expression as > > > a first-class object which encapsulates the > underlying technology. > > > > > > > > > Since most impls are (they generate their own > parse trees etc.) and > > any intermediate "first-class object" simply gets > in the way IMO. > > > > > > The first-class Expression object encapsulates the > specifics of the > implementation (whether it be a String or some > Serializable object or > whatever). This way, you just code to the > commons-expression API > (getValue/setValue) rather than carrying around some > string. Also, > the implementations are free to "compile" their > expressions so that > they perform better (the MVEL implementation does > this and it smokes > all of the others in my simple benchmarking, because > I can't get OGNL > to compile its expression without a "root object" > from the beginning). > > > > > > > > > (5) The [proxy] APIs have bled into your > proposal. While thats > > > > completely understandable in a PoC since you > have the [proxy] usecase > > > > in mind, we will have to clean that up. > Perhaps [proxy] or [scxml] > > > > might need a subinterface or equivalent of > the cleaner [expression] > > > > APIs, we'll have to see. If [expression] > makes progress, I'd want > > > > [scxml] to depend on it. > > > > > > > > > > Well, the builder idea does require proxies to > get it to work. I'm > > > using the InvocationRecorder support from Proxy > to achieve this. I > > > could pull that stuff out of proxy and into > [expression] if others see > > > that as necessary. I think the builder idea is > a very nice addition, > > > though. It's like being able to create an > anonymous inner class in > > > Java without having to create the class. It's > almost like having a > > > closure (albeit a limited one)! :) > > > > > > > > > I'd like [expression] to have no dependencies > (other than the ELs > > themselves, for the various adapters). > > Well, the builder idea can't be done without using > proxies. And, you > can't do the type of proxies necessary for the > majority of cases (ones > that extend classes rather than implement > interfaces) using the JDK > proxy support only. So, you're going to have to > have a dependency > there somewhere (assuming you like the Builder > idea). I'd rather use > Proxy for this since that's its job. It knows how > to make proxies > using various technologies and I don't want to have > to think about > that in this library. Proxy doesn't have any > required dependencies > out of the box. It would, of course, require > dependencies based on > which proxying technology you choose to use in your > builders. Without having looked at the code, I'm not understanding why [proxy] would be a "first-class" dependency. Seems like it would be optional depending on whether a client of [expression?] wanted to use the recording implementation. I still agree with Rahul that object graph navigation is the commonality here. But once you remove the concept of an integral String representation it seems like generic functor stuff to me. JXPath has Pointers that behave somewhat like what you're suggesting, James, but ultimately they are still tied to the original syntactic representation. Of course, "object graph navigation" is 3/4 of OGNL's name, isn't it? I MIGHT be able to accept the recording implementation as an "expression" if you at least made the toString() of the recording present something expressionlike: e.g. record < getFoo() getBar() getBaz() > toString(): "getFoo().getBar().getBaz()" -Matt > > > > > > > I can put my existing code into the sandbox to > bootstrap it. I have > > > access to the sandbox. I just wanted to make > sure nobody completely > > > objected to the idea behind [expression] with > respect to the commons > > > in general. > > > > > > > > > I think we may have sufficiently different ideas > on what we need to > > begin playing in different sandboxes. > > > > That also means we need two component names. I do > think the name > > [expression] would be misleading for the idea > you've proposed. In > > fact, thats what got me thinking we wanted > similar things :-) Any > > alternatives I could think of suggesting were a > bit long for my taste, > > I'll keep trying. I'd like to use the > [expression] for the > > Context+Evaluator API, which is quite a common > theme in many first > > class expression language impls. > > If people feel that [expression] isn't the right > name for what I've > come up with, I don't really care (as I said, wha
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 1:59 PM, James Carman
<[EMAIL PROTECTED]> wrote:
> On Thu, Apr 10, 2008 at 1:46 PM, James Carman
> <[EMAIL PROTECTED]> wrote:
> > If people feel that [expression] isn't the right name for what I've
> > come up with, I don't really care (as I said, what's in a name). But,
> > the idea of an expression just fit in my mind. I'll try to come up
> > with something else if you're really that opposed to me using the name
> > "expression". The term "macro" came to mind when I was thinking about
> > a name for this thing, since the builders are essentially recording
> > something from the user (on a proxy) that will later be played back
> > (on some other object).
> >
>
> Other words that convey a similar idea:
>
> variable - the "expression" is really a variable (a value that can be
> modified or retrieved).
> value - the "expression" represents a settable/gettable "value"
> shortcut - the "expression" is a shortcut for calling a (potentially)
> chained series of method calls
> flatten - the "expression" flattens the chained series of method calls
>
To spell out the "macro" API, it would be:
public interface Macro
{
public V getValue(R root);
public void setValue(R root, V value);
}
public interface Recorder
{
public R template();
public Macro record(V value);
}
A usage would look like:
Recorder recorder = ...;
Macro addressCityMacro =
recorder.record(recorder.template().getAddress().getCity());
Person p = ...;
String city = addressCityMacro.getValue(p);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r646842 - /commons/sandbox/exec/trunk/src/test/scripts/forever.sh
Hi Sebb, But that does not work on e.g. FreeBSD. Indeed the code will now just create an ever-larger file, not print ... to the screen +) printing the funny dots was just something I ommited to delete - I want to make a verification to ensure that the script was executed successfully by ensure that the file exists and is not empty +) would the statement would work on FreeBSD in general? Cheers, Siegfried Goeschl sebb wrote: On 10/04/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: sgoeschl Date: Thu Apr 10 08:22:17 2008 New Revision: 646842 URL: http://svn.apache.org/viewvc?rev=646842&view=rev Log: Changed the usage of the echo statement to work with HP-UX (thanks to sebb) Modified: commons/sandbox/exec/trunk/src/test/scripts/forever.sh Modified: commons/sandbox/exec/trunk/src/test/scripts/forever.sh URL: http://svn.apache.org/viewvc/commons/sandbox/exec/trunk/src/test/scripts/forever.sh?rev=646842&r1=646841&r2=646842&view=diff == --- commons/sandbox/exec/trunk/src/test/scripts/forever.sh (original) +++ commons/sandbox/exec/trunk/src/test/scripts/forever.sh Thu Apr 10 08:22:17 2008 @@ -22,6 +22,5 @@ while test "notempty" do sleep 1 - echo -n . - # echo -n . >> ./target/forever.txt + echo '.\c' >> ./target/forever.txt But that does not work on e.g. FreeBSD. Indeed the code will now just create an ever-larger file, not print ... to the screen done - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 1:46 PM, James Carman <[EMAIL PROTECTED]> wrote: > If people feel that [expression] isn't the right name for what I've > come up with, I don't really care (as I said, what's in a name). But, > the idea of an expression just fit in my mind. I'll try to come up > with something else if you're really that opposed to me using the name > "expression". The term "macro" came to mind when I was thinking about > a name for this thing, since the builders are essentially recording > something from the user (on a proxy) that will later be played back > (on some other object). > Other words that convey a similar idea: variable - the "expression" is really a variable (a value that can be modified or retrieved). value - the "expression" represents a settable/gettable "value" shortcut - the "expression" is a shortcut for calling a (potentially) chained series of method calls flatten - the "expression" flattens the chained series of method calls - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 12:12 PM, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > I don't know about this API. The idea behind [expression] is that > > it's not necessarily string-based (a lot of the impls are, but the > > Javassist one wouldn't be; it'll probably only be available via > > builder). The [expression] project strives to treat the expression as > > a first-class object which encapsulates the underlying technology. > > > > > Since most impls are (they generate their own parse trees etc.) and > any intermediate "first-class object" simply gets in the way IMO. > > The first-class Expression object encapsulates the specifics of the implementation (whether it be a String or some Serializable object or whatever). This way, you just code to the commons-expression API (getValue/setValue) rather than carrying around some string. Also, the implementations are free to "compile" their expressions so that they perform better (the MVEL implementation does this and it smokes all of the others in my simple benchmarking, because I can't get OGNL to compile its expression without a "root object" from the beginning). > > > > > > (5) The [proxy] APIs have bled into your proposal. While thats > > > completely understandable in a PoC since you have the [proxy] usecase > > > in mind, we will have to clean that up. Perhaps [proxy] or [scxml] > > > might need a subinterface or equivalent of the cleaner [expression] > > > APIs, we'll have to see. If [expression] makes progress, I'd want > > > [scxml] to depend on it. > > > > > > > Well, the builder idea does require proxies to get it to work. I'm > > using the InvocationRecorder support from Proxy to achieve this. I > > could pull that stuff out of proxy and into [expression] if others see > > that as necessary. I think the builder idea is a very nice addition, > > though. It's like being able to create an anonymous inner class in > > Java without having to create the class. It's almost like having a > > closure (albeit a limited one)! :) > > > > > I'd like [expression] to have no dependencies (other than the ELs > themselves, for the various adapters). Well, the builder idea can't be done without using proxies. And, you can't do the type of proxies necessary for the majority of cases (ones that extend classes rather than implement interfaces) using the JDK proxy support only. So, you're going to have to have a dependency there somewhere (assuming you like the Builder idea). I'd rather use Proxy for this since that's its job. It knows how to make proxies using various technologies and I don't want to have to think about that in this library. Proxy doesn't have any required dependencies out of the box. It would, of course, require dependencies based on which proxying technology you choose to use in your builders. > > > > I can put my existing code into the sandbox to bootstrap it. I have > > access to the sandbox. I just wanted to make sure nobody completely > > objected to the idea behind [expression] with respect to the commons > > in general. > > > > > I think we may have sufficiently different ideas on what we need to > begin playing in different sandboxes. > > That also means we need two component names. I do think the name > [expression] would be misleading for the idea you've proposed. In > fact, thats what got me thinking we wanted similar things :-) Any > alternatives I could think of suggesting were a bit long for my taste, > I'll keep trying. I'd like to use the [expression] for the > Context+Evaluator API, which is quite a common theme in many first > class expression language impls. If people feel that [expression] isn't the right name for what I've come up with, I don't really care (as I said, what's in a name). But, the idea of an expression just fit in my mind. I'll try to come up with something else if you're really that opposed to me using the name "expression". The term "macro" came to mind when I was thinking about a name for this thing, since the builders are essentially recording something from the user (on a proxy) that will later be played back (on some other object). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r646842 - /commons/sandbox/exec/trunk/src/test/scripts/forever.sh
On 10/04/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: sgoeschl > Date: Thu Apr 10 08:22:17 2008 > New Revision: 646842 > > URL: http://svn.apache.org/viewvc?rev=646842&view=rev > Log: > Changed the usage of the echo statement to work with HP-UX (thanks to sebb) > > Modified: > commons/sandbox/exec/trunk/src/test/scripts/forever.sh > > Modified: commons/sandbox/exec/trunk/src/test/scripts/forever.sh > URL: > http://svn.apache.org/viewvc/commons/sandbox/exec/trunk/src/test/scripts/forever.sh?rev=646842&r1=646841&r2=646842&view=diff > > == > --- commons/sandbox/exec/trunk/src/test/scripts/forever.sh (original) > +++ commons/sandbox/exec/trunk/src/test/scripts/forever.sh Thu Apr 10 > 08:22:17 2008 > @@ -22,6 +22,5 @@ > while test "notempty" > do >sleep 1 > - echo -n . > - # echo -n . >> ./target/forever.txt > + echo '.\c' >> ./target/forever.txt But that does not work on e.g. FreeBSD. Indeed the code will now just create an ever-larger file, not print ... to the screen > done > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j2me commons?
On Thu, Apr 10, 2008 at 10:00 AM, Nick Burch <[EMAIL PROTECTED]> wrote: > Hi All > > I've been chatting to a few people at ApacheCon about a j2me commons, and > they suggested I bring the idea to the dev list. > I'm one of those people. > My idea was to have a commons library that implemented all the common > things you want to do for j2me, which have annoyingly been missed out of > the j2me spec, or are quite hard to do. > > Currently, I have a few functions that I've written for a project, which > I'm happy to apache license. What I also have is tests for them, and some > ant magic which allows you to build them on j2se, and also to unit test > them on j2se, against a j2me class library (assuming you have the sun wtk > installed somewhere) > > > Do people think this is worth putting in as a new sandbox component? I'm > happy to oversee the new component, if people are happy for me to put it > in (+grant myself appropriate svn karma to do so) > I think we need a different name ( not [j2me] ). Please try to define a scope via a proposal ( see recent example: http://markmail.org/message/4z6z4zendcusdcnu ) -- its great for archival so I like those things :-) All - I suggest we let Nick have a go at it. The scope / component size question raised is real. I think we will have a better idea when we see the code. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 8:21 AM, James Carman
<[EMAIL PROTECTED]> wrote:
> On Thu, Apr 10, 2008 at 7:56 AM, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> >
> > (1) The proposed API feels like [objectgraphnavigation] rather than
> > [expression], which is an interesting subset of expressions, but
> > limiting nevertheless. I'm interested in the latter, and also think it
> > makes the former redundant.
> >
>
> Yes, primarily it deals with object graph navigation, but the
> Expression implementations can support more complex scenarios via the
> underlying technology.
>
With a bit of a disconnect.
> > (2) I'd like to claim that [expression] is a solved problem ;-)
> > [scxml] requires pluggable expression languages and already has an
> > abstraction over ELs:
> >
> > http://commons.apache.org/scxml/guide/contexts-evaluators.html
> >
> > The core of [expression] should consist of two interfaces (I'm happy
> > to do this by cleaning up the corresponding bits in [scxml]):
> >
> > public interface Context {
> > Object get(String name);
> > void set(String name, Object value);
> > }
> >
> > public interface Evaluator {
> > Object evaluate(String expression, Context context)
> > throws EvaluationException;
> > Context newContext(Context parent);
> > }
>
> I don't know about this API. The idea behind [expression] is that
> it's not necessarily string-based (a lot of the impls are, but the
> Javassist one wouldn't be; it'll probably only be available via
> builder). The [expression] project strives to treat the expression as
> a first-class object which encapsulates the underlying technology.
>
Since most impls are (they generate their own parse trees etc.) and
any intermediate "first-class object" simply gets in the way IMO.
> >
> > To summarize, generally the above abstraction has worked well.
>
> I didn't consider JavaScript, but that's an interesting idea.
> >
Its one of the popular requests.
> > (3) Generics don't buy us much in terms of type safety / correctness
> > guarantees for [expression]. Lets not use them (easier to support 1.4
> > that way, for example).
> >
>
> I would have to disagree with this. The API I'm using makes the code
> easier to read, IMHO. I would want it to use generics. No, it
> doesn't necessarily *guarantee* type safety (as evidenced by the
> @SuppressWarnings("unchecked) in the code), but it doesn't hurt by
> having it there and makes it easier to use the code in other libraries
> (like Wicket; I can imagine a Wicket ExpressionModel which extends
> IModel).
>
Unconvinced, but moving on.
> > (4) I don't think of BeanUtils as an expression language, or JXPath
> > for that matter (relates to point 1 above a bit). That doesn't mean
> > there can't be corresponding Evaluator implementations, just means
> > users of those implementations will need to understand the limitations
> > (and we will need to document them). For example, don't ask the
> > BeanUtils evaluator to evaluate "22 / 7".
>
> BeanUtils does support "expressions" in that they have their own
> expression syntax for referring to bean properties. That's why I
> chose to support it. The same goes for JXPath.
>
I agree, as I said its limited as-is (to bean property / object graph
navigation) and not a first class expression language. Nothing against
having those adapters.
> >
> > (5) The [proxy] APIs have bled into your proposal. While thats
> > completely understandable in a PoC since you have the [proxy] usecase
> > in mind, we will have to clean that up. Perhaps [proxy] or [scxml]
> > might need a subinterface or equivalent of the cleaner [expression]
> > APIs, we'll have to see. If [expression] makes progress, I'd want
> > [scxml] to depend on it.
> >
>
> Well, the builder idea does require proxies to get it to work. I'm
> using the InvocationRecorder support from Proxy to achieve this. I
> could pull that stuff out of proxy and into [expression] if others see
> that as necessary. I think the builder idea is a very nice addition,
> though. It's like being able to create an anonymous inner class in
> Java without having to create the class. It's almost like having a
> closure (albeit a limited one)! :)
>
I'd like [expression] to have no dependencies (other than the ELs
themselves, for the various adapters).
> > I suggest we use the interfaces above, I can bootstrap [expression] in
> > the sandbox per those.
> >
>
> I can put my existing code into the sandbox to bootstrap it. I have
> access to the sandbox. I just wanted to make sure nobody completely
> objected to the idea behind [expression] with respect to the commons
> in general.
>
I think we may have sufficiently different ideas on what we need to
begin playing in different sandboxes.
That also means we need two component names. I do think the name
[expression] would be misleading for the idea you've proposed. In
fact, thats what got me thinking we wanted similar things :-) Any
alterna
Re: j2me commons?
On Thu, 10 Apr 2008, James Carman wrote: > That sounds more like something that would be a top-level-project, > IMHO. Possibly much longer term, if there was the interest to sustain it! > I could see multiple modules in something like J2ME Commons. I'm sure > there isn't a standard set of "things you want to do for j2me." I would > assume (having never written for the J2ME platform) that there are > various categories of "things" you'd want to do. Most j2me programs get passed through pre-processors which strip out un-used classes and methods, before being packaged for the phone. So, in theory, it wouldn't matter too much if we gathered quite a lot of code in one library initially, as people would only end up with what they need on the phone (I'm not sure how much interest there will be in a j2me commons, as most phones have very open source hostile security rules, lack of open source friendly dev environments etc, so there might not be a huge ecosystem of developers) Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j2me commons?
That sounds more like something that would be a top-level-project, IMHO. I could see multiple modules in something like J2ME Commons. I'm sure there isn't a standard set of "things you want to do for j2me." I would assume (having never written for the J2ME platform) that there are various categories of "things" you'd want to do. On Thu, Apr 10, 2008 at 10:00 AM, Nick Burch <[EMAIL PROTECTED]> wrote: > Hi All > > I've been chatting to a few people at ApacheCon about a j2me commons, and > they suggested I bring the idea to the dev list. > > My idea was to have a commons library that implemented all the common > things you want to do for j2me, which have annoyingly been missed out of > the j2me spec, or are quite hard to do. > > Currently, I have a few functions that I've written for a project, which > I'm happy to apache license. What I also have is tests for them, and some > ant magic which allows you to build them on j2se, and also to unit test > them on j2se, against a j2me class library (assuming you have the sun wtk > installed somewhere) > > > Do people think this is worth putting in as a new sandbox component? I'm > happy to oversee the new component, if people are happy for me to put it > in (+grant myself appropriate svn karma to do so) > > Nick > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
j2me commons?
Hi All I've been chatting to a few people at ApacheCon about a j2me commons, and they suggested I bring the idea to the dev list. My idea was to have a commons library that implemented all the common things you want to do for j2me, which have annoyingly been missed out of the j2me spec, or are quite hard to do. Currently, I have a few functions that I've written for a project, which I'm happy to apache license. What I also have is tests for them, and some ant magic which allows you to build them on j2se, and also to unit test them on j2se, against a j2me class library (assuming you have the sun wtk installed somewhere) Do people think this is worth putting in as a new sandbox component? I'm happy to oversee the new component, if people are happy for me to put it in (+grant myself appropriate svn karma to do so) Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum] BUILD FAILURE: Commons Monitoring (Sandbox)
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=75465&projectId=538
Build statistics:
State: Failed
Previous State: Ok
Started at: Thu 10 Apr 2008 06:44:30 -0700
Finished at: Thu 10 Apr 2008 06:45:04 -0700
Total time: 34s
Build Trigger: Schedule
Build Number: 4
Exit code: 1
Building machine hostname: vmbuild.apache.org
Operating system : Linux(unknown)
Java Home version :
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)
Builder version :
Maven version: 2.0.7
Java version: 1.5.0_12
OS name: "linux" version: "2.6.20-16-server" arch: "i386"
SCM Changes:
Changed: nicolas @ Thu 10 Apr 2008 02:02:07 -0700
Comment: generate Flot graph output
Files changed:
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/listeners/HistorizedRepositoryDecorator.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/AbstractRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/FlotRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/HtmlRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/JsonRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/OptionsSupport.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/Renderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/TxtRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/XmlRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/web/MonitoringServlet.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/web/NiceHtmlRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/test/java/org/apache/commons/monitoring/reporting/RendererTest.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/test/resources/org/apache/commons/monitoring/reporting/RendererTest.flot
( 646698 )
Changed: nicolas @ Thu 10 Apr 2008 02:14:34 -0700
Comment: test fix
Files changed:
/commons/sandbox/monitoring/trunk/src/test/resources/org/apache/commons/monitoring/reporting/RendererTest.flot
( 646704 )
Dependencies Changes:
No dependencies changed
Build Defintion:
POM filename: pom.xml
Goals: clean deploy
Arguments: --batch-mode -DaltDeploymentRepository=vmbuild.repo::default::file://localhost/home/continuum/data/commons -Pci
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Java 5
Description:
Test Summary:
Tests: 27
Failures: 1
Total time: 3498
Output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Commons Monitoring (Sandbox)
[INFO]task-segment: [clean, deploy]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /home/continuum/data/working-directory/538/target
[INFO] Deleting directory
/home/continuum/data/working-directory/538/target/classes
[INFO] Deleting directory
/home/continuum/data/working-directory/538/target/test-classes
[INFO] Deleting directory /home/continuum/data/working-directory/538/target/site
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
[copy] Copying 2 files to
/home/continuum/data/working-directory/538/target/apidocs/META-INF
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 62 source files to
/home/continuum/data/working-directory/538/target/classes
[INFO] [resources:testResources]
[INFO] Using default encod
[continuum] BUILD FAILURE: Commons Monitoring (Sandbox)
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=75465&projectId=538
Build statistics:
State: Failed
Previous State: Ok
Started at: Thu 10 Apr 2008 06:44:30 -0700
Finished at: Thu 10 Apr 2008 06:45:04 -0700
Total time: 34s
Build Trigger: Schedule
Build Number: 4
Exit code: 1
Building machine hostname: vmbuild.apache.org
Operating system : Linux(unknown)
Java Home version :
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)
Builder version :
Maven version: 2.0.7
Java version: 1.5.0_12
OS name: "linux" version: "2.6.20-16-server" arch: "i386"
SCM Changes:
Changed: nicolas @ Thu 10 Apr 2008 02:02:07 -0700
Comment: generate Flot graph output
Files changed:
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/listeners/HistorizedRepositoryDecorator.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/AbstractRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/FlotRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/HtmlRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/JsonRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/OptionsSupport.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/Renderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/TxtRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/XmlRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/web/MonitoringServlet.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/main/java/org/apache/commons/monitoring/reporting/web/NiceHtmlRenderer.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/test/java/org/apache/commons/monitoring/reporting/RendererTest.java
( 646698 )
/commons/sandbox/monitoring/trunk/src/test/resources/org/apache/commons/monitoring/reporting/RendererTest.flot
( 646698 )
Changed: nicolas @ Thu 10 Apr 2008 02:14:34 -0700
Comment: test fix
Files changed:
/commons/sandbox/monitoring/trunk/src/test/resources/org/apache/commons/monitoring/reporting/RendererTest.flot
( 646704 )
Dependencies Changes:
No dependencies changed
Build Defintion:
POM filename: pom.xml
Goals: clean deploy
Arguments: --batch-mode -DaltDeploymentRepository=vmbuild.repo::default::file://localhost/home/continuum/data/commons -Pci
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Java 5
Description:
Test Summary:
Tests: 27
Failures: 1
Total time: 3498
Output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Commons Monitoring (Sandbox)
[INFO]task-segment: [clean, deploy]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /home/continuum/data/working-directory/538/target
[INFO] Deleting directory
/home/continuum/data/working-directory/538/target/classes
[INFO] Deleting directory
/home/continuum/data/working-directory/538/target/test-classes
[INFO] Deleting directory /home/continuum/data/working-directory/538/target/site
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
[copy] Copying 2 files to
/home/continuum/data/working-directory/538/target/apidocs/META-INF
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 62 source files to
/home/continuum/data/working-directory/538/target/classes
[INFO] [resources:testResources]
[INFO] Using default encod
[Collections] .obj1 and .obj2 file types
data/test/NullComparator.version2.obj1 data/test/NullComparator.version2.obj2 seem to be versions of .obj files. it's a bit confusing to create new file types - and it messes up various settings and tools - so could these be renamed as .obj, but with a different stem? Or are the different extensions essential? S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Collections] SVN eol-style fix
svn ps svn:eol-style native src/test/org/apache/commons/collections/map/TestMultiValueMap.java Needs to be done in trunk; perhaps also in active branches. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 7:56 AM, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> No, I support this and would like to work on it.
>
That's great! I would love to have some help/input on this.
> Thanks a lot, this is great. I was lost reading the emails in this
> thread but the code has made things much clearer.
>
> I have some immediate comments:
>
> (1) The proposed API feels like [objectgraphnavigation] rather than
> [expression], which is an interesting subset of expressions, but
> limiting nevertheless. I'm interested in the latter, and also think it
> makes the former redundant.
>
Yes, primarily it deals with object graph navigation, but the
Expression implementations can support more complex scenarios via the
underlying technology.
> (2) I'd like to claim that [expression] is a solved problem ;-)
> [scxml] requires pluggable expression languages and already has an
> abstraction over ELs:
>
> http://commons.apache.org/scxml/guide/contexts-evaluators.html
>
> The core of [expression] should consist of two interfaces (I'm happy
> to do this by cleaning up the corresponding bits in [scxml]):
>
> public interface Context {
> Object get(String name);
> void set(String name, Object value);
> }
>
> public interface Evaluator {
> Object evaluate(String expression, Context context)
> throws EvaluationException;
> Context newContext(Context parent);
> }
I don't know about this API. The idea behind [expression] is that
it's not necessarily string-based (a lot of the impls are, but the
Javassist one wouldn't be; it'll probably only be available via
builder). The [expression] project strives to treat the expression as
a first-class object which encapsulates the underlying technology.
>
> Names TBD etc.
>
> SAMPLE USAGE (untested, ofcourse):
>
> Evaluator evaluator = new JexlEvaluator(); // Use JEXL, for example
>
> Context context = evaluator.newContext(null);
> context.put(...);
>
> try {
> /*Some type*/ result = evaluator.evaluate("...", context);
> } catch (EvaluationExpression ee) {
> // ...
> }
>
> We have proven implementations of this in [scxml] land for:
> * EL (JSP 2.0 and a variant with a bit of JSF MBEs thrown in as well)
> * Commons JEXL
> * JavaScript (by way of Rhino)
> * Various (by way of javax.script)
> * Pnuts
>
> Other comments:
> * I've done adapters for two proprietary ELs
> * MVEL would be trivial
> * I'm not familiar with its OGNL APIs, will take a look later
>
> To summarize, generally the above abstraction has worked well.
I didn't consider JavaScript, but that's an interesting idea.
>
> (3) Generics don't buy us much in terms of type safety / correctness
> guarantees for [expression]. Lets not use them (easier to support 1.4
> that way, for example).
>
I would have to disagree with this. The API I'm using makes the code
easier to read, IMHO. I would want it to use generics. No, it
doesn't necessarily *guarantee* type safety (as evidenced by the
@SuppressWarnings("unchecked) in the code), but it doesn't hurt by
having it there and makes it easier to use the code in other libraries
(like Wicket; I can imagine a Wicket ExpressionModel which extends
IModel).
> (4) I don't think of BeanUtils as an expression language, or JXPath
> for that matter (relates to point 1 above a bit). That doesn't mean
> there can't be corresponding Evaluator implementations, just means
> users of those implementations will need to understand the limitations
> (and we will need to document them). For example, don't ask the
> BeanUtils evaluator to evaluate "22 / 7".
BeanUtils does support "expressions" in that they have their own
expression syntax for referring to bean properties. That's why I
chose to support it. The same goes for JXPath.
>
> (5) The [proxy] APIs have bled into your proposal. While thats
> completely understandable in a PoC since you have the [proxy] usecase
> in mind, we will have to clean that up. Perhaps [proxy] or [scxml]
> might need a subinterface or equivalent of the cleaner [expression]
> APIs, we'll have to see. If [expression] makes progress, I'd want
> [scxml] to depend on it.
>
Well, the builder idea does require proxies to get it to work. I'm
using the InvocationRecorder support from Proxy to achieve this. I
could pull that stuff out of proxy and into [expression] if others see
that as necessary. I think the builder idea is a very nice addition,
though. It's like being able to create an anonymous inner class in
Java without having to create the class. It's almost like having a
closure (albeit a limited one)! :)
> I suggest we use the interfaces above, I can bootstrap [expression] in
> the sandbox per those.
>
I can put my existing code into the sandbox to bootstrap it. I have
access to the sandbox. I just wanted to make sure nobody completely
objected to the idea behind [expression] with respect to the commons
in general.
---
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 11:18 PM, James Carman
<[EMAIL PROTECTED]> wrote:
> On Wed, Apr 9, 2008 at 9:47 PM, James Carman <[EMAIL PROTECTED]> wrote:
> > So, does anyone object to me putting this code into the sandbox?
No, I support this and would like to work on it.
> > I've
> > got working versions of expressions and builders (with test cases of
> > course) for:
> >
> > MVEL
> > OGNL
> > BeanUtils
> > JXPath
> >
>
> If you're interested, I set it up in my own SVN repository while I was
> working on it:
>
> http://svn.carmanconsulting.com/public/commons-expression/trunk
>
Thanks a lot, this is great. I was lost reading the emails in this
thread but the code has made things much clearer.
I have some immediate comments:
(1) The proposed API feels like [objectgraphnavigation] rather than
[expression], which is an interesting subset of expressions, but
limiting nevertheless. I'm interested in the latter, and also think it
makes the former redundant.
(2) I'd like to claim that [expression] is a solved problem ;-)
[scxml] requires pluggable expression languages and already has an
abstraction over ELs:
http://commons.apache.org/scxml/guide/contexts-evaluators.html
The core of [expression] should consist of two interfaces (I'm happy
to do this by cleaning up the corresponding bits in [scxml]):
public interface Context {
Object get(String name);
void set(String name, Object value);
}
public interface Evaluator {
Object evaluate(String expression, Context context)
throws EvaluationException;
Context newContext(Context parent);
}
Names TBD etc.
SAMPLE USAGE (untested, ofcourse):
Evaluator evaluator = new JexlEvaluator(); // Use JEXL, for example
Context context = evaluator.newContext(null);
context.put(...);
try {
/*Some type*/ result = evaluator.evaluate("...", context);
} catch (EvaluationExpression ee) {
// ...
}
We have proven implementations of this in [scxml] land for:
* EL (JSP 2.0 and a variant with a bit of JSF MBEs thrown in as well)
* Commons JEXL
* JavaScript (by way of Rhino)
* Various (by way of javax.script)
* Pnuts
Other comments:
* I've done adapters for two proprietary ELs
* MVEL would be trivial
* I'm not familiar with its OGNL APIs, will take a look later
To summarize, generally the above abstraction has worked well.
(3) Generics don't buy us much in terms of type safety / correctness
guarantees for [expression]. Lets not use them (easier to support 1.4
that way, for example).
(4) I don't think of BeanUtils as an expression language, or JXPath
for that matter (relates to point 1 above a bit). That doesn't mean
there can't be corresponding Evaluator implementations, just means
users of those implementations will need to understand the limitations
(and we will need to document them). For example, don't ask the
BeanUtils evaluator to evaluate "22 / 7".
(5) The [proxy] APIs have bled into your proposal. While thats
completely understandable in a PoC since you have the [proxy] usecase
in mind, we will have to clean that up. Perhaps [proxy] or [scxml]
might need a subinterface or equivalent of the cleaner [expression]
APIs, we'll have to see. If [expression] makes progress, I'd want
[scxml] to depend on it.
I suggest we use the interfaces above, I can bootstrap [expression] in
the sandbox per those.
-Rahul
> Enjoy!
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r646693 - /commons/sandbox/exec/trunk/build.xml
On 10/04/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: sgoeschl
> Date: Thu Apr 10 01:53:36 2008
> New Revision: 646693
>
> URL: http://svn.apache.org/viewvc?rev=646693&view=rev
> Log:
> Creating a proper name for test distribution, e.g.
> exec-test-1.0-SNAPSHOT.zip't
Some hosts don't have zip - can you also create a tar.gz please?
>
> Modified:
> commons/sandbox/exec/trunk/build.xml
>
> Modified: commons/sandbox/exec/trunk/build.xml
> URL:
> http://svn.apache.org/viewvc/commons/sandbox/exec/trunk/build.xml?rev=646693&r1=646692&r2=646693&view=diff
>
> ==
> --- commons/sandbox/exec/trunk/build.xml (original)
> +++ commons/sandbox/exec/trunk/build.xml Thu Apr 10 01:53:36 2008
> @@ -98,7 +98,7 @@
>
> ==
>
>
> - description="Create a zip containing the test environment">
> +
>
>
> todir="${maven.build.directory}/dist/lib"/>
> @@ -111,7 +111,7 @@
>
>
>
> - destfile="${maven.build.directory}/exec-${maven.build.version}.zip">
> + destfile="${maven.build.directory}/exec-test-${maven.build.version}.zip">
>
>
>
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Oliver Heger a écrit : XMLConfiguration and XMLPropertiesConfiguration remain in the main package. Why? The purpose of the package is to group only the SAX readers as they form a hierarchy providing a specific feature, just like the BeanUtils bridge in the beanutils package. I don't know if these classes are frequently used, actually I don't know the use cases for these readers. As a non core feature I don't think they deserve to remain in the main package. I don't think moving the XMLConfiguration and XMLPropertiesConfiguration classes in an xml package is necessary, I don't have any problem with them staying in the main package. Also, that would not make sense to move them but not XMLPropertyListConfiguration in the plist package, and having XMLPropertyListConfiguration outside the plist package seems absurds too. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r646661 - in /commons/proper/configuration/branches/configuration2_experimental/src: main/java/org/apache/commons/configuration2/ main/java/org/apache/commons/configuration2/flat/ test
[EMAIL PROTECTED] a écrit : -List list = PropertyConverter.split((String) value, getListDelimiter()); +List list = PropertyConverter.split((String) value, +getListDelimiter()); Oliver, could you increase the line length setting of your IDE to 120 please ? Wrapping at 80 characters is quite restrictive and doesn't improve the readability. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
