Re: [configuration] New hierarchical configurations
Oliver Heger a écrit : I would like to keep main package pretty small, so that it only contains the basic interfaces and abstract base classes. Sub packages would group classes with similar functionality. The plist and web packages are good examples for that, but I am not sure how to handle specific implementations consisting of only one or two classes (e.g. INIConfiguration). Putting them in their own package probably does not make too much sense. I see a package change that might be worth considering : the 3 XMLReader classes form a group that could be put in a sub package, o.a.c.c.xml or o.a.c.c.sax. What do you think ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-functor (in module commons-sandbox) failed
On Wed, Apr 9, 2008 at 10:36 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: The descriptor said maven which is Maven1, I changed it to mvn (Gump speak for Maven2) so I hope it will work better on the next run. Thanks Stefan Niall Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-functor (in module commons-sandbox) failed
The descriptor said maven which is Maven1, I changed it to mvn (Gump speak for Maven2) so I hope it will work better on the next run. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-functor (in module commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-functor has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-functor : Functor: Function Objects Full details are available at: http://vmgump.apache.org/gump/public/commons-sandbox/commons-functor/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-functor-08042008.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-sandbox/functor/build.properties -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-sandbox/commons-functor/gump_work/build_commons-sandbox_commons-functor.html Work Name: build_commons-sandbox_commons-functor (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-sandbox/functor] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/commons-sandbox/functor/target/classes:/srv/gump/public/workspace/commons-sandbox/functor/target/test-classes:/srv/gump/public/workspace/commons-sandbox/functor/src/test:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/junit/dist/junit-08042008.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependency: jsch-0.1.5.jar Total time: 3 seconds Finished at: Tue Apr 08 08:51:13 GMT-08:00 2008 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-sandbox/commons-functor/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-sandbox/commons-functor/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 16000808042008, vmgump:vmgump-public:16000808042008 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] 3.3 issues
Just curious, what's the current state? In Apache Sling we would need an OSGi enabled release in two weeks :) Now, don't get me wrong, I don't want to push or force you to do a release (especially as I'm not able to help with the open issues). I would just like to know, if it might be possible that we have the release by then? If not, it's no problem, and we'll create an interims wrapper bundle and switch to the release as soon as it is available. Carsten Henri Yandell wrote: Here's a peek at some of the interesting issues in the 3.3 TODO list that need discussion: * COLLECTIONS-238 - Allowing ExtendedProperties to have empty values. ie) foo= would result in a key of foo existing. Is anyone concerned about backwards compatibility with that? I'm happy with it - it seems to me that it is how that should have worked, and people shouldn't be commenting out by removing the value rather than putting a comment in front. * Serializable - COLLECTIONS-240, COLLECTIONS-285, COLLECTIONS-221, COLLECTIONS-267, COLLECTIONS-266. Basically we need some Serializable test love. * COLLECTIONS-265 is ready for committing. So any nay-sayers, speak now or reopen later. * Specifically for James Carman - how does Dave's patch to your COLLECTIONS-194 look? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Expression API?
On Sun, Apr 6, 2008 at 4:43 PM, Matt Benson [EMAIL PROTECTED] wrote: I'm still hoping to bring Morph on board soon, and its current codebase contains several facets including a Language abstraction. I really think there's some overlap there with [el], but another piece of Morph is its Reflector APIs which are similar to BeanUtils' DynaBean, and I'm thinking the Reflector APIs could go far toward providing a useful abstraction to plug arbitrary object types into expression evaluators. Matt, I took a brief look at Morph and the Language interface. I like the idea, but I'm looking for something a bit more object-oriented (not that Morph isn't, I'm just saying my idea goes 0.0001 percent more in the OO direction :). I'm looking to take the String parameter out of the get/set method's API. I want an object that represents a gettable and (potentially) settable expression. Would that be something that goes into Morph? The Wicket folks are looking for something somewhat soon. I was just wondering if this idea was something we could get into one of our current projects (or if it even belongs there). Perhaps I can start a sandbox project for my ideas. What I have in mind is implementations using such things as: Javassist MVEL OGNL JXPath JSTL-EL There would be implementations of Expression for each of those. Also, there would be builders that would allow you to use Java to build up the expression which could be played back later. So, you would do something like: builder.recorder().getAddress().getCity(); Expression e = builder.createExpression(); Somehow we could get this on one line, but the idea is similar to how EasyMock (or JMock) works. You perform operations on the proxied recorder (proxy already has this built-in now) and it remembers what you did. Then you ask the recorder to build an Expression object which allows you to replay what you just did at a later date on the same type of root object (it would allow you to set that value also). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DISCUSS] New Expressions Sandbox Project...
I wanted to start up a discussion about maybe starting a new sandbox
project for expression abstraction. It could be named
commons-expresso. I realize that there's a J2EE framework out there
called Expresso, but its site hasn't been updated since 2005, so I
don't know how active it is or if this would even be a conflict
anyway. I don't really care what it's called. I just care about the
content.
For those who have not been reading the other threads, I would like to
create a project which allows us to abstract the idea of an
expression in Java. Here's the main interface:
public interface Expression
{
public Object getValue(Object root);
public void setValue(Object root, Object value);
}
This could be generified to perhaps:
public interface ExpressionR,V
{
public V getValue(R root);
public void setValue(R root, V value);
}
Anyway, the guts of the project would be the implementations of this
interface. I have plans to implement it using the following
technologies for now (please add suggestions if you have them):
Javassist
MVEL
OGNL
JSTL-EL
JXPath
That's just a preliminary list, but you get the idea of the sort of
thing I'm looking for. Matt Benson has suggested that this sort of
thing might be best suited to go into his Morph project currently
located at Sourceforge. Currently, it doesn't have anything like
this. The project would also contain expression builder
implementations which would allow you to use Java to build up the
expression:
public interface ExpressionBuilderR
{
public R recorder();
public V ExpresionR,V buildExpression(V value);
}
Example usage:
ExpressionBuilder builder = new JavassistExpressionBuilderPerson();
ExpressionPerson,String expr =
builder.buildExpression(builder.recorder().getAddress().getCity());
Person p = ...;
String city = expr.getValue(p);
The cool thing about this is that you can switch the expression
implementation without changing how you build up the expression!
Thoughts anyone?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
2008/4/9, James Carman [EMAIL PROTECTED]: I realize that there's a J2EE framework out there called Expresso, but its site hasn't been updated since 2005, so I don't know how active it is or if this would even be a conflict anyway. There is already a regular-expression tool called Expresso: http://www.ultrapico.com/Expresso.htm Come on, James, express yourself better :-D Antonio
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: There is already a regular-expression tool called Expresso: http://www.ultrapico.com/Expresso.htm Come on, James, express yourself better :-D Thanks, Antonio. :) Ok, I googled only shortly to look for something (I think I typed expresso java and looked at the first couple of hits). Again, I don't care about the name, but I do like it. I'd go for commons-expression (or commons-express) just as easily, though. I'm mainly concerned with the content. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
--- James Carman [EMAIL PROTECTED] wrote:
I wanted to start up a discussion about maybe
starting a new sandbox
project for expression abstraction. It could be
named
commons-expresso. I realize that there's a J2EE
framework out there
called Expresso, but its site hasn't been updated
since 2005, so I
don't know how active it is or if this would even be
a conflict
anyway. I don't really care what it's called. I
just care about the
content.
For those who have not been reading the other
threads, I would like to
create a project which allows us to abstract the
idea of an
expression in Java. Here's the main interface:
public interface Expression
{
public Object getValue(Object root);
public void setValue(Object root, Object value);
}
This could be generified to perhaps:
public interface ExpressionR,V
{
public V getValue(R root);
public void setValue(R root, V value);
}
Anyway, the guts of the project would be the
implementations of this
interface. I have plans to implement it using the
following
technologies for now (please add suggestions if you
have them):
Javassist
MVEL
OGNL
JSTL-EL
JXPath
That's just a preliminary list, but you get the idea
of the sort of
thing I'm looking for. Matt Benson has suggested
that this sort of
thing might be best suited to go into his Morph
project currently
located at Sourceforge.
Actually, to clarify, Morph isn't mine. Matt
Sgarlata is the primary developer; I just came in
midway and started helping out (at least I like to
think my input has been helpful)... then, I wasn't
necessarily suggesting that new work on the expression
concept should go into Morph, either. Actually I see
Morph being broken down into smaller pieces once we
get it into Commons. It sounds like you're suggesting
a package similar to [proxy]/[logging]/[openpgp] whose
basic purpose is to provide a common interface over
various similar underlying technologies. I honestly
think Morph @ Commons would ultimately have its
Language facilities removed or moved elsewhere, so
maybe there's not much overlap here beyond the idea
that your proposed project might conceivably contain
one or more built-in implementations, and one of these
might be derived from Morph's basic Language
implementation, SimpleLanguage.
Currently, it doesn't have
anything like
this. The project would also contain expression
builder
implementations which would allow you to use Java to
build up the
expression:
public interface ExpressionBuilderR
{
public R recorder();
public V ExpresionR,V buildExpression(V
value);
}
Example usage:
ExpressionBuilder builder = new
JavassistExpressionBuilderPerson();
ExpressionPerson,String expr =
builder.buildExpression(builder.recorder().getAddress().getCity());
Person p = ...;
String city = expr.getValue(p);
The cool thing about this is that you can switch the
expression
implementation without changing how you build up the
expression!
Thoughts anyone?
This would qualify as one of the built-in expression
engines I mentioned before, really. So... you're
suggesting that _most_ of the expression factory
implementations supported by this proposition would be
built from Strings, but that it wouldn't necessarily
be so all the time? How are you intending your
recordable implementation to be able to handle set vs.
get operations, though? I don't get that from your
example.
-Matt
-
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...
On 09/04/2008, James Carman [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: There is already a regular-expression tool called Expresso: http://www.ultrapico.com/Expresso.htm Come on, James, express yourself better :-D Thanks, Antonio. :) Ok, I googled only shortly to look for something (I think I typed expresso java and looked at the first couple of hits). Again, I don't care about the name, but I do like it. I'd go for commons-expression (or commons-express) just as easily, though. I'm mainly concerned with the content. Anyway, the name would be [Apache] Commons Expresso, not just Expresso. - 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...
--- James Carman [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: There is already a regular-expression tool called Expresso: http://www.ultrapico.com/Expresso.htm Come on, James, express yourself better :-D Thanks, Antonio. :) Ok, I googled only shortly to look for something (I think I typed expresso java and looked at the first couple of hits). Again, I don't care about the name, but I do like it. I'd go for commons-expression (or commons-express) just as easily, though. I'm mainly concerned with the content. I'm not convinced that, once you remove the constraint of a String representation, that what you are talking about is necessarily an expression. Also given the concern I brought up about recording, explicitly calling getters doesn't AFAICT obviously yield a result that knows how to accomplish a setValue. -Matt - 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...
On Wed, Apr 9, 2008 at 10:24 AM, Matt Benson [EMAIL PROTECTED] wrote: Actually, to clarify, Morph isn't mine. Matt Sgarlata is the primary developer; I just came in midway and started helping out (at least I like to think my input has been helpful)... then, I wasn't necessarily suggesting that new work on the expression concept should go into Morph, either. I apologize. I thought the project was yours. My mistake. This would qualify as one of the built-in expression engines I mentioned before, really. So... you're suggesting that _most_ of the expression factory implementations supported by this proposition would be built from Strings, but that it wouldn't necessarily be so all the time? How are you intending your recordable implementation to be able to handle set vs. get operations, though? I don't get that from your example. Yes, most of them would be based on Strings (we'd probably have a superclass for string-based expressions). But, Javassist would actually generate a class at runtime to evaluate the expression. As for how we provide set operations, the recorder basically records what you have done, what methods you called and their parameters. Then, the builder looks at that information and figures out how to build up the expression so that it's settable. Ognl provides this sort of thing out of the box (see the Ognl.setValue method I think it's called); the string basically points to a value and you can use that string to set/get either way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
2008/4/9, sebb [EMAIL PROTECTED]: On 09/04/2008, James Carman [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: There is already a regular-expression tool called Expresso: http://www.ultrapico.com/Expresso.htm Come on, James, express yourself better :-D Thanks, Antonio. :) Ok, I googled only shortly to look for something (I think I typed expresso java and looked at the first couple of hits). Again, I don't care about the name, but I do like it. I'd go for commons-expression (or commons-express) just as easily, though. I'm mainly concerned with the content. Anyway, the name would be [Apache] Commons Expresso, not just Expresso. It doesn't matter, at Tiles we were refused the name of Dimensions for Apache Tiles Dimensions because Dimensions is already a piece of software. We needed to rename it (FYI it is Kaolin). Antonio
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 10:28 AM, Matt Benson [EMAIL PROTECTED] wrote: I'm not convinced that, once you remove the constraint of a String representation, that what you are talking about is necessarily an expression. Also given the concern I brought up about recording, explicitly calling getters doesn't AFAICT obviously yield a result that knows how to accomplish a setValue. Yes, the builder would be somewhat limited. It wouldn't allow you to build expressions for stuff like indexing into arrays or other more complex situations, but it would cover the simple property traversal situations. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 7:18 AM, James Carman [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: There is already a regular-expression tool called Expresso: http://www.ultrapico.com/Expresso.htm Come on, James, express yourself better :-D Thanks, Antonio. :) Ok, I googled only shortly to look for something (I think I typed expresso java and looked at the first couple of hits). Again, I don't care about the name, but I do like it. I'd go for commons-expression (or commons-express) just as easily, though. I'm mainly concerned with the content. The Commons rule is (or at least was) that Commons components should have boring functional names, so Commons Expression would fit, but Commons Expresso would not. (Yes, there are some components that do not conform, but they existed prior to the instigation of the rule.) -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 10:34 AM, Martin Cooper [EMAIL PROTECTED] wrote: The Commons rule is (or at least was) that Commons components should have boring functional names, so Commons Expression would fit, but Commons Expresso would not. (Yes, there are some components that do not conform, but they existed prior to the instigation of the rule.) No big deal. What's in a name? That which we call a rose by any other name would smell as sweet! Ooooh! I've got it! How about comons-rose? ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EXEC] Help needed for regression testing ...
Hi folks, commons-exec (see http://commons.apache.org/sandbox/exec/) is about running external processes from within a JVM - and there are a lot of OS and JVM versions out there (plus a lot of code in commons-exec to handle this). So if you feel adventurous and have some time to spare ... +) I uploaded a self-contained test distribution to http://people.apache.org/~sgoeschl/download/commons-exec/exec-test-1.0-SNAPSHOT.zip +) If you unpack the zip file you are able to start the regression tests using 'sh ./testme.sh or 'testme.bat' +) Make sure that you have $JAVA_HOME defined as environment variable to pick up your Java installation to be used +) It runs all regression tests without requiring to have ANT or Maven installed +) Send a quick feedback about the test result and the OS/JVM being used so I can update the website Thanks in advance Siegfried Goeschl PS: Please, don't run the tests on a mission-critical super-important box - some of the tests are quite heavy (e.g. starting thousand processes to make sure that we don't have any memory/handle leaks) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] 3.3 issues
On Wed, Apr 9, 2008 at 1:17 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Just curious, what's the current state? In Apache Sling we would need an OSGi enabled release in two weeks :) Now, don't get me wrong, I don't want to push or force you to do a release (especially as I'm not able to help with the open issues). I would just like to know, if it might be possible that we have the release by then? If not, it's no problem, and we'll create an interims wrapper bundle and switch to the release as soon as it is available. From looking at JIRA theres currently 10 open issues left targetted at 3.3. Not sure how much effort would be involved in getting those fixed - hopefully Henri will respond on that and how likely/soon he thinks they will get fixed for a 3.3 release. Perhaps if its going to be a while before 3.3 release gets out, then we could just release Collections 3.2.1 which is just 3.2 re-packaged ready for OSGi. I could do that if 3.3 is going to be delayed. Niall Carsten Henri Yandell wrote: Here's a peek at some of the interesting issues in the 3.3 TODO list that need discussion: * COLLECTIONS-238 - Allowing ExtendedProperties to have empty values. ie) foo= would result in a key of foo existing. Is anyone concerned about backwards compatibility with that? I'm happy with it - it seems to me that it is how that should have worked, and people shouldn't be commenting out by removing the value rather than putting a comment in front. * Serializable - COLLECTIONS-240, COLLECTIONS-285, COLLECTIONS-221, COLLECTIONS-267, COLLECTIONS-266. Basically we need some Serializable test love. * COLLECTIONS-265 is ready for committing. So any nay-sayers, speak now or reopen later. * Specifically for James Carman - how does Dave's patch to your COLLECTIONS-194 look? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Carsten Ziegeler [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 Wed, Apr 9, 2008 at 10:28 AM, Matt Benson [EMAIL PROTECTED] wrote: I'm not convinced that, once you remove the constraint of a String representation, that what you are talking about is necessarily an expression. Also given the concern I brought up about recording, explicitly calling getters doesn't AFAICT obviously yield a result that knows how to accomplish a setValue. Also, what I'm proposing would be in the sandbox, so maybe I can get some code in there so that we can look at it. If we don't like it, we can remove it or make it dormant. I just wanted to make sure that the idea of the project doesn't go against the charter. I guess in the strictest sense, it does, since it's somewhat of a framework. Then again, so is proxy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EXEC] Help needed for regression testing ...
On 09/04/2008, Siegfried Goeschl [EMAIL PROTECTED] wrote: Hi folks, commons-exec (see http://commons.apache.org/sandbox/exec/) is about running external processes from within a JVM - and there are a lot of OS and JVM versions out there (plus a lot of code in commons-exec to handle this). So if you feel adventurous and have some time to spare ... +) I uploaded a self-contained test distribution to http://people.apache.org/~sgoeschl/download/commons-exec/exec-test-1.0-SNAPSHOT.zip +) If you unpack the zip file you are able to start the regression tests using 'sh ./testme.sh or 'testme.bat' +) Make sure that you have $JAVA_HOME defined as environment variable to pick up your Java installation to be used +) It runs all regression tests without requiring to have ANT or Maven installed +) Send a quick feedback about the test result and the OS/JVM being used so I can update the website Thanks in advance Siegfried Goeschl PS: Please, don't run the tests on a mission-critical super-important box - some of the tests are quite heavy (e.g. starting thousand processes to make sure that we don't have any memory/handle leaks) Is it possible to skip these tests? Are they OS-dependent - i.e. do they need to be run on all OSes? - 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: [EXEC] Help needed for regression testing ...
Hi I feel really bad about not giving commons-exec the love it needs. Nice to see some additional testing going on with the code. Have you found any bugs that need fixing? Could we include these tests as part of the exec project? I would be happy to help out with the integration if needed. In addition to our unit tests we could have an integration test suite. If so, I would like them to run from our maven build, do you foresee any issues with that? /niklas On Wed, Apr 9, 2008 at 4:47 PM, Siegfried Goeschl [EMAIL PROTECTED] wrote: Hi folks, commons-exec (see http://commons.apache.org/sandbox/exec/) is about running external processes from within a JVM - and there are a lot of OS and JVM versions out there (plus a lot of code in commons-exec to handle this). So if you feel adventurous and have some time to spare ... +) I uploaded a self-contained test distribution to http://people.apache.org/~sgoeschl/download/commons-exec/exec-test-1.0-SNAPSHOT.zip +) If you unpack the zip file you are able to start the regression tests using 'sh ./testme.sh or 'testme.bat' +) Make sure that you have $JAVA_HOME defined as environment variable to pick up your Java installation to be used +) It runs all regression tests without requiring to have ANT or Maven installed +) Send a quick feedback about the test result and the OS/JVM being used so I can update the website Thanks in advance Siegfried Goeschl PS: Please, don't run the tests on a mission-critical super-important box - some of the tests are quite heavy (e.g. starting thousand processes to make sure that we don't have any memory/handle leaks) - 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: [EXEC] Help needed for regression testing ...
Hi Siegfried, run on : - Linux Gentoo (2.6.22-mactel-r2 #1 SMP PREEMPT Thu Nov 15 23:26:36 CET 2007 i686 Intel(R) Core(TM)2 CPU T7600 @ 2.33GHz GenuineIntel GNU/Linux) ... JVM Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) - Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode) : 55 tests ok ... JVM Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_13-b06) - Java HotSpot(TM) Client VM (build 1.4.2_13-b06, mixed mode) : 55 tests ok ... JVM Java(TM) SE Runtime Environment (build 1.6.0_03-b05) - Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode) : 55 tests ok - OSX : 8.11.1 Darwin Kernel Version 8.11.1 ... JVM Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing) Hope this helps, Simone Siegfried Goeschl wrote: Hi folks, commons-exec (see http://commons.apache.org/sandbox/exec/) is about running external processes from within a JVM - and there are a lot of OS and JVM versions out there (plus a lot of code in commons-exec to handle this). So if you feel adventurous and have some time to spare ... +) I uploaded a self-contained test distribution to http://people.apache.org/~sgoeschl/download/commons-exec/exec-test-1.0-SNAPSHOT.zip +) If you unpack the zip file you are able to start the regression tests using 'sh ./testme.sh or 'testme.bat' +) Make sure that you have $JAVA_HOME defined as environment variable to pick up your Java installation to be used +) It runs all regression tests without requiring to have ANT or Maven installed +) Send a quick feedback about the test result and the OS/JVM being used so I can update the website Thanks in advance Siegfried Goeschl PS: Please, don't run the tests on a mission-critical super-important box - some of the tests are quite heavy (e.g. starting thousand processes to make sure that we don't have any memory/handle leaks) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simone Gianni http://www.simonegianni.it/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] 3.3 issues
On Wed, Apr 9, 2008 at 7:52 AM, Niall Pemberton [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 1:17 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Just curious, what's the current state? In Apache Sling we would need an OSGi enabled release in two weeks :) Now, don't get me wrong, I don't want to push or force you to do a release (especially as I'm not able to help with the open issues). I would just like to know, if it might be possible that we have the release by then? If not, it's no problem, and we'll create an interims wrapper bundle and switch to the release as soon as it is available. From looking at JIRA theres currently 10 open issues left targetted at 3.3. Of those, I think these are the important ones and others can be punted: https://issues.apache.org/jira/browse/COLLECTIONS-240 https://issues.apache.org/jira/browse/COLLECTIONS-285 https://issues.apache.org/jira/browse/COLLECTIONS-266 https://issues.apache.org/jira/browse/COLLECTIONS-221 Basically the serializing issues. Not sure how much effort would be involved in getting those fixed - hopefully Henri will respond on that and how likely/soon he thinks they will get fixed for a 3.3 release. I doubt a release would be out in 2 weeks. If all issues were fixed, 2 weeks would probably be the length of time needed to get the release out, so you've got the code above to add onto that and no one has been volunteering to dig into the pain of figuring out the serialization tests :) Perhaps if its going to be a while before 3.3 release gets out, then we could just release Collections 3.2.1 which is just 3.2 re-packaged ready for OSGi. I could do that if 3.3 is going to be delayed. Might be worth it. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EXEC] Help needed for regression testing ...
Hi Simone, thanks a lot for your effort - considering the fact that I nearly killed Niall's box yesterday I'm happy that it runs smoothly on your box(es) Cheers, Siegfried Goeschl Simone Gianni wrote: Hi Siegfried, run on : - Linux Gentoo (2.6.22-mactel-r2 #1 SMP PREEMPT Thu Nov 15 23:26:36 CET 2007 i686 Intel(R) Core(TM)2 CPU T7600 @ 2.33GHz GenuineIntel GNU/Linux) ... JVM Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) - Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode) : 55 tests ok ... JVM Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_13-b06) - Java HotSpot(TM) Client VM (build 1.4.2_13-b06, mixed mode) : 55 tests ok ... JVM Java(TM) SE Runtime Environment (build 1.6.0_03-b05) - Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode) : 55 tests ok - OSX : 8.11.1 Darwin Kernel Version 8.11.1 ... JVM Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing) Hope this helps, Simone Siegfried Goeschl wrote: Hi folks, commons-exec (see http://commons.apache.org/sandbox/exec/) is about running external processes from within a JVM - and there are a lot of OS and JVM versions out there (plus a lot of code in commons-exec to handle this). So if you feel adventurous and have some time to spare ... +) I uploaded a self-contained test distribution to http://people.apache.org/~sgoeschl/download/commons-exec/exec-test-1.0-SNAPSHOT.zip +) If you unpack the zip file you are able to start the regression tests using 'sh ./testme.sh or 'testme.bat' +) Make sure that you have $JAVA_HOME defined as environment variable to pick up your Java installation to be used +) It runs all regression tests without requiring to have ANT or Maven installed +) Send a quick feedback about the test result and the OS/JVM being used so I can update the website Thanks in advance Siegfried Goeschl PS: Please, don't run the tests on a mission-critical super-important box - some of the tests are quite heavy (e.g. starting thousand processes to make sure that we don't have any memory/handle leaks) - 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...
Excuse the top post, but there isn't much context to
what I want to say.
Beyond what I've already said wrt Morph, its Language
concept does allow for setting and getting from
expressions, as do those various libraries to which
James plans to interface. But Morph also contains a
Reflector abstraction, which I have suggested is
suited to be a discrete Commons component. Morph
implements a Language with a Reflector. The only
difference between the two is that a Reflector is
intended to set/get a property exactly one level
removed from the source object. Perhaps that is an
unnecessary distinction and the [expression] idea is
really another way of expressing the need for generic
reflectors that can get/set a -possibly nested-
property given a root object (BeanUtils and Spring
have also implemented this basic requirement as well).
I don't think this POV invalidates Morph's existing
single-level Reflectors, nor do I see any real
conflict with complex Reflectors being dependent on
simple Reflectors.
To address the other part of your proposal, James, the
record/playback mechanism: wouldn't the resulting
object be a functor a la [functor]? A get would be a
function, a set a procedure.
-Matt
--- James Carman [EMAIL PROTECTED] wrote:
I wanted to start up a discussion about maybe
starting a new sandbox
project for expression abstraction. It could be
named
commons-expresso. I realize that there's a J2EE
framework out there
called Expresso, but its site hasn't been updated
since 2005, so I
don't know how active it is or if this would even be
a conflict
anyway. I don't really care what it's called. I
just care about the
content.
For those who have not been reading the other
threads, I would like to
create a project which allows us to abstract the
idea of an
expression in Java. Here's the main interface:
public interface Expression
{
public Object getValue(Object root);
public void setValue(Object root, Object value);
}
This could be generified to perhaps:
public interface ExpressionR,V
{
public V getValue(R root);
public void setValue(R root, V value);
}
Anyway, the guts of the project would be the
implementations of this
interface. I have plans to implement it using the
following
technologies for now (please add suggestions if you
have them):
Javassist
MVEL
OGNL
JSTL-EL
JXPath
That's just a preliminary list, but you get the idea
of the sort of
thing I'm looking for. Matt Benson has suggested
that this sort of
thing might be best suited to go into his Morph
project currently
located at Sourceforge. Currently, it doesn't have
anything like
this. The project would also contain expression
builder
implementations which would allow you to use Java to
build up the
expression:
public interface ExpressionBuilderR
{
public R recorder();
public V ExpresionR,V buildExpression(V
value);
}
Example usage:
ExpressionBuilder builder = new
JavassistExpressionBuilderPerson();
ExpressionPerson,String expr =
builder.buildExpression(builder.recorder().getAddress().getCity());
Person p = ...;
String city = expr.getValue(p);
The cool thing about this is that you can switch the
expression
implementation without changing how you build up the
expression!
Thoughts anyone?
-
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...
On Wed, Apr 9, 2008 at 3:01 PM, Matt Benson [EMAIL PROTECTED] wrote: To address the other part of your proposal, James, the record/playback mechanism: wouldn't the resulting object be a functor a la [functor]? A get would be a function, a set a procedure. Yes, they would, and I was planning on providing adapters to that effect. I wouldn't necessarily code to the functor API, but you could use the Expression object as a function by wrapping it with the adapter class. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Emmanuel Bourg schrieb: Oliver Heger a écrit : I would like to keep main package pretty small, so that it only contains the basic interfaces and abstract base classes. Sub packages would group classes with similar functionality. The plist and web packages are good examples for that, but I am not sure how to handle specific implementations consisting of only one or two classes (e.g. INIConfiguration). Putting them in their own package probably does not make too much sense. I see a package change that might be worth considering : the 3 XMLReader classes form a group that could be put in a sub package, o.a.c.c.xml or o.a.c.c.sax. What do you think ? Emmanuel Bourg Would XMLConfiguration also go into this package? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] Generics and Return Type?
Does anyone have code that can take care of this situation: ListString strings = new ArrayListString(); Class returnType = getReturnType(strings.getClass(), get, int.class); I want the returnType to be java.lang.String. Does anyone have code that would return that? Is it possible? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Generics and Return Type?
2008/4/9, James Carman [EMAIL PROTECTED]: Does anyone have code that can take care of this situation: ListString strings = new ArrayListString(); Class returnType = getReturnType(strings.getClass(), get, int.class); I want the returnType to be java.lang.String. Does anyone have code that would return that? Is it possible? It's not possible: http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html snip Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler. /snip Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Oliver Heger a écrit : Would XMLConfiguration also go into this package? XMLConfiguration and XMLPropertiesConfiguration remain in the main package. In this regard the package name o.a.c.c.sax would make more sense. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EXEC] Help needed for regression testing ...
Hello Siegfried, On Wed, Apr 9, 2008 at 8:47 AM, Siegfried Goeschl [EMAIL PROTECTED] wrote: Hi folks, commons-exec (see http://commons.apache.org/sandbox/exec/) is about running external processes from within a JVM - and there are a lot of OS and JVM versions out there (plus a lot of code in commons-exec to handle this). So if you feel adventurous and have some time to spare ... +) I uploaded a self-contained test distribution to http://people.apache.org/~sgoeschl/download/commons-exec/exec-test-1.0-SNAPSHOT.zip +) If you unpack the zip file you are able to start the regression tests using 'sh ./testme.sh or 'testme.bat' +) Make sure that you have $JAVA_HOME defined as environment variable to pick up your Java installation to be used +) It runs all regression tests without requiring to have ANT or Maven installed +) Send a quick feedback about the test result and the OS/JVM being used so I can update the website I tested the zip on a couple of my boxes and all tests passed, the results are pasted below. Win Vista Ultimate 64 bit | JDK 1.3.1_20 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.4.2_17 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.5.0_15 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.5.0_15x64 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.6.0_05 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.6.0_05x64 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.7.0ea_b24 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.7.0ea_b24x64 - OK (55 tests) Win XP Pro 32 bit | JDK 1.4.2_17 - OK (55 tests) Win XP Pro 32 bit | JDK 1.5.0_15 - OK (55 tests) Win XP Pro 32 bit | JDK 1.6.0_05 - OK (55 tests) Fedora Core 7 on VmWare | JDK 1.4.2_17 - OK (55 tests) Fedora Core 7 on VmWare | JDK 1.5.0_15 - OK (55 tests) Fedora Core 7 on VmWare | JDK 1.6.0_05 - OK (55 tests) Hope this helps. Thanks in advance Siegfried Goeschl PS: Please, don't run the tests on a mission-critical super-important box - some of the tests are quite heavy (e.g. starting thousand processes to make sure that we don't have any memory/handle leaks) Regards, Bindul -- Bindul Bhowmik | MindTree Ltd. | www.mindtree.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Generics and Return Type?
Well, I figured out a way to have proxy determine the type of a method
when doing invocation recording. It took me a while, but I got it.
The code is checked into the proxy 2.0 branch. Now, I've got my
builders working for commons-expression, too! :)
On Wed, Apr 9, 2008 at 6:30 PM, Michael Heuer [EMAIL PROTECTED] wrote:
On Wed, 9 Apr 2008, Antonio Petrelli wrote:
2008/4/9, James Carman [EMAIL PROTECTED]:
Does anyone have code that can take care of this situation:
ListString strings = new ArrayListString();
Class returnType = getReturnType(strings.getClass(), get, int.class);
I want the returnType to be java.lang.String. Does anyone have code
that would return that? Is it possible?
It's not possible:
http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html
snip
Generics are implemented by type erasure: generic type information is
present only at compile time, after which it is erased by the
compiler.
/snip
Right, you can get at the declared type(s) with e.g.
ListString strings = new ArrayListString();
ParameterizedType parameterizedType = (ParameterizedType)
strings.getClass().getGenericSuperclass();
Type[] types = parameterizedType.getActualTypeArguments();
System.out.println(Arrays.asList(types));
[E]
static class StringList extends ArrayListString { }
ListString strings = new StringList();
ParameterizedType parameterizedType = (ParameterizedType)
strings.getClass().getGenericSuperclass();
Type[] types = parameterizedType.getActualTypeArguments();
System.out.println(Arrays.asList(types));
[class java.lang.String]
but not the runtime type(s).
michael
-
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 Wed, Apr 9, 2008 at 3:01 PM, Matt Benson [EMAIL PROTECTED] wrote: Excuse the top post, but there isn't much context to what I want to say. Beyond what I've already said wrt Morph, its Language concept does allow for setting and getting from expressions, as do those various libraries to which James plans to interface. But Morph also contains a Reflector abstraction, which I have suggested is suited to be a discrete Commons component. Morph implements a Language with a Reflector. The only difference between the two is that a Reflector is intended to set/get a property exactly one level removed from the source object. Perhaps that is an unnecessary distinction and the [expression] idea is really another way of expressing the need for generic reflectors that can get/set a -possibly nested- property given a root object (BeanUtils and Spring have also implemented this basic requirement as well). I don't think this POV invalidates Morph's existing single-level Reflectors, nor do I see any real conflict with complex Reflectors being dependent on simple Reflectors. To address the other part of your proposal, James, the record/playback mechanism: wouldn't the resulting object be a functor a la [functor]? A get would be a function, a set a procedure. So, does anyone object to me putting this code into the sandbox? I've got working versions of expressions and builders (with test cases of course) for: MVEL OGNL BeanUtils JXPath - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EXEC] Help needed for regression testing ...
On 10/04/2008, Bindul Bhowmik [EMAIL PROTECTED] wrote: Hello Siegfried, On Wed, Apr 9, 2008 at 8:47 AM, Siegfried Goeschl [EMAIL PROTECTED] wrote: Hi folks, commons-exec (see http://commons.apache.org/sandbox/exec/) is about running external processes from within a JVM - and there are a lot of OS and JVM versions out there (plus a lot of code in commons-exec to handle this). So if you feel adventurous and have some time to spare ... +) I uploaded a self-contained test distribution to http://people.apache.org/~sgoeschl/download/commons-exec/exec-test-1.0-SNAPSHOT.zip +) If you unpack the zip file you are able to start the regression tests using 'sh ./testme.sh or 'testme.bat' +) Make sure that you have $JAVA_HOME defined as environment variable to pick up your Java installation to be used +) It runs all regression tests without requiring to have ANT or Maven installed +) Send a quick feedback about the test result and the OS/JVM being used so I can update the website I tested the zip on a couple of my boxes and all tests passed, the results are pasted below. Win Vista Ultimate 64 bit | JDK 1.3.1_20 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.4.2_17 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.5.0_15 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.5.0_15x64 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.6.0_05 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.6.0_05x64 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.7.0ea_b24 - OK (55 tests) Win Vista Ultimate 64 bit | JDK 1.7.0ea_b24x64 - OK (55 tests) Win XP Pro 32 bit | JDK 1.4.2_17 - OK (55 tests) Win XP Pro 32 bit | JDK 1.5.0_15 - OK (55 tests) Win XP Pro 32 bit | JDK 1.6.0_05 - OK (55 tests) Fedora Core 7 on VmWare | JDK 1.4.2_17 - OK (55 tests) Fedora Core 7 on VmWare | JDK 1.5.0_15 - OK (55 tests) Fedora Core 7 on VmWare | JDK 1.6.0_05 - OK (55 tests) Hope this helps. == WinXP == java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260-20071123_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20071121_15015 (JIT enabled) J9VM - 20071121_015015_lHdSMR JIT - r9_20071121_1330 GC - 20071031_AA) JCL - 20071118_01 java version 1.4.2_17 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_17-b06) Java HotSpot(TM) Client VM (build 1.4.2_17-b06, mixed mode) java version 1.6.0_05 Java(TM) SE Runtime Environment (build 1.6.0_05-b13) Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing) == HP-UX == java version 1.4.2.10 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2.10-060112-14:28) Java HotSpot(TM) Server VM (build 1.4.2 1.4.2.10-060112-19:42-IA64N IA64, mixed mode) $ uname -a HP-UX td194 B.11.31 U ia64 3426292962 unlimited-user license All the above tests passed. == OpenVMS == HP rx2600 (1.40GHz/1.5MB) running OpenVMS V8.3 java version 1.4.2 Java(TM) 2 Runtime Environment, Standard Edition Java HotSpot(TM) Server VM (build 1.4.2-2 11/03/2005-08:43 IA64, mixed mode) Tests run: 55, Failures: 18, Errors: 0 The failures all seem to be due to: Test not supported for this OS I tried to emulate the script files in DCL, but they may be wrong... Thanks in advance Siegfried Goeschl PS: Please, don't run the tests on a mission-critical super-important box - some of the tests are quite heavy (e.g. starting thousand processes to make sure that we don't have any memory/handle leaks) Regards, Bindul -- Bindul Bhowmik | MindTree Ltd. | www.mindtree.com - 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]
[EMAIL PROTECTED]: Project commons-compress (in module commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-compress has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 40 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-compress : Commons Compression Package Full details are available at: http://vmgump.apache.org/gump/public/commons-sandbox/commons-compress/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-compress-09042008.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-sandbox/compress/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-sandbox/compress/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-sandbox/compress/project.properties -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-sandbox/commons-compress/gump_work/build_commons-sandbox_commons-compress.html Work Name: build_commons-sandbox_commons-compress (Type: Build) Work ended in a state of : Failed Elapsed: 16 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-sandbox/compress] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/junit/dist/junit-09042008.jar:/srv/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependency: jsch-0.1.5.jar Total time: 15 seconds Finished at: Wed Apr 09 02:16:45 GMT-08:00 2008 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-sandbox/commons-compress/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-sandbox/commons-compress/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 5909042008, vmgump:vmgump-public:5909042008 Gump E-mail Identifier (unique within run) #12. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-functor (in module commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-functor has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-functor : Functor: Function Objects Full details are available at: http://vmgump.apache.org/gump/public/commons-sandbox/commons-functor/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-functor-1.0-SNAPSHOT.jar] identifier set to project name -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/commons-sandbox/functor/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-sandbox/functor/pom.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-sandbox/commons-functor/gump_work/build_commons-sandbox_commons-functor.html Work Name: build_commons-sandbox_commons-functor (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: mvn --settings /srv/gump/public/workspace/commons-sandbox/functor/gump_mvn_settings.xml jar [Working Directory: /srv/gump/public/workspace/commons-sandbox/functor] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/junit/dist/junit-09042008.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [INFO] Scanning for projects... Downloading: http://localhost:8192/maven2/org/apache/commons/commons-sandbox-parent/4/commons-sandbox-parent-4.pom 3/3K 3K downloaded Downloading: http://localhost:8192/maven2/org/apache/commons/commons-parent/8/commons-parent-8.pom 4/20K 8/20K 12/20K 16/20K 20/20K 20/20K 20K downloaded [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'jar': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Apr 09 02:28:37 GMT-08:00 2008 [INFO] Final Memory: 1M/2M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-sandbox/commons-functor/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-sandbox/commons-functor/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 5909042008, vmgump:vmgump-public:5909042008 Gump E-mail Identifier (unique within run) #17. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
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? 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 Enjoy! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jux (in module commons-dormant) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jux has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jux : JUX: JUnit Extensions Full details are available at: http://vmgump.apache.org/gump/public/commons-dormant/commons-jux/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jux-09042008.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-dormant/jux/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-dormant/jux/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-dormant/jux/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-dormant/commons-jux/gump_work/build_commons-dormant_commons-jux.html Work Name: build_commons-dormant_commons-jux (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-dormant/jux] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/commons-dormant/jux/target/classes:/srv/gump/public/workspace/commons-dormant/jux/target/test-classes:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/junit/dist/junit-09042008.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependency: jsch-0.1.5.jar Total time: 2 seconds Finished at: Wed Apr 09 03:07:10 GMT-08:00 2008 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-dormant/commons-jux/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-dormant/commons-jux/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 5909042008, vmgump:vmgump-public:5909042008 Gump E-mail Identifier (unique within run) #23. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-primitives (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-primitives has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-primitives : Provides a collection of types and utilities optimized for w... Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-primitives/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-primitives-09042008.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/apache-commons/primitives/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/primitives/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/apache-commons/primitives/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-primitives/gump_work/build_apache-commons_commons-primitives.html Work Name: build_apache-commons_commons-primitives (Type: Build) Work ended in a state of : Failed Elapsed: 5 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/apache-commons/primitives] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/primitives/target/classes:/srv/gump/public/workspace/apache-commons/primitives/target/test-classes:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/srv/gump/public/workspace/apache-commons/collections/build/commons-collections-testframework-09042008.jar: /srv/gump/packages/jdepend-2.6/lib/jdepend.jar:/srv/gump/public/workspace/junit/dist/junit-09042008.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependency: jsch-0.1.5.jar Total time: 4 seconds Finished at: Wed Apr 09 03:36:36 GMT-08:00 2008 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-primitives/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-primitives/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 5909042008, vmgump:vmgump-public:5909042008 Gump E-mail Identifier (unique within run) #31. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] New hierarchical configurations
Emmanuel Bourg schrieb: Oliver Heger a écrit : Would XMLConfiguration also go into this package? XMLConfiguration and XMLPropertiesConfiguration remain in the main package. Why? Oliver In this regard the package name o.a.c.c.sax would make more sense. Emmanuel Bourg - 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]
