Re: svn commit: r367531 [1/2] - in /jakarta/commons/sandbox/javaflow/trunk: ./ src/test/org/apache/commons/javaflow/ src/test/org/apache/commons/javaflow/bytecode/transformation/ src/test/org/apache/c

[Kohsuke Kawaguchi]

[EMAIL PROTECTED] wrote:

+
+  commons-io
+  commons-io
+  20050621.133116
+


I noticed that you added a non-standard version of commons-io. Is this 
intentional? It seems to compile just fine even if I switch the build to 
commons-io-1.1.


I started using javaflow for my workflow engine 
(http://dalma.dev.java.net/). Therefore, if possible, I'd prefer to have 
simpler dependencies --- so that my users can get all the necessary jars 
easily.


--
Kohsuke Kawaguchi
Sun Microsystems   [EMAIL PROTECTED]


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [vote] access for Niklas Gustavsson to the sandbox

[Henri Yandell]

karma granted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[csv] feature and performance analysis

[Henri Yandell]

Spent a little time over the last week doing both performance and
feature set analysis of the 5 open-source CSV libraries that I'm aware
of.

First up, feature sets:

http://people.apache.org/~bayard/commons-csv/csv-features.xhtml

Secondly, performance. The code/data is sitting in:

http://people.apache.org/~bayard/commons-csv/csv-perf/

Run under 1.5 because the Ostermiller library is compiled for 1.5 [grumble].

Results

http://people.apache.org/~bayard/commons-csv/csv-perf/results.csv

Take with a grain of salt, these aren't quite the pattern I was seeing
when running a few days ago on the plane. Ideally needs to run
multiple time and take median or some such.

Generally, Ostermiller is fastest for parsing, with Skife then Open a
chunk behind. GJ a little behind them and Commons lagging by a lot.

On printing, Open edges Skife, GJ a bit behind, Commons and then
Ostermiller lagging a lot.

-=-=-=-=-=-=-=-=-=-=-=-=-=-

What did I learn from this.

* Lots of features out there, no library contains all of them. I don't
think that many of them are mutually exclusive.

* Ostermiller's parser is very quick. Possibly because he's built on
top of JFlex? The printer is very, very slow.

* The current Commons parser is very slow. As is the printer.

* I also did some bug checking. Given that I only had 7 quick lines of
pain, I don't think any parser managed to parse them with much
success: http://people.apache.org/~bayard/commons-csv/csv-perf/dependability.csv

Mostly; that despite the odd looks I get when I mention having a
commons-csv (people think they're dumb simple things), we all have
lots of room for improvement.

-

So what next? Are the poor performance stats for Commons-CSV a worry?
Are they offset enough by having more features? Should we look into a
lexical tool approach as it seems to work for Ostermiller?

Class-wise, I'd like to see something like:

Csv (instead of using String[][] or List of String[])
CsvPrinter
CsvParser
CsvException
CsvStrategy  (used by both printer and parser)

I don't see any reason to not want every feature in the feature file.

That's it for the night. If you're not on commons-dev, mail
[EMAIL PROTECTED] to join in. Cc's are unlikely
to last too long on a thread. Make sure you keep the [csv] on the
emails and future ones, useful way of separating the components out.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [id] Review before 1.0 (Summary)

[Phil Steitz]

On 1/14/06, Michael Heuer <[EMAIL PROTECTED]> wrote:
>
> Jörg Schaible wrote:
>
> > 8/ Prefix generators
> >
> > We have 3 generators, that add a prefix to the generated id. All 3 classes
> > to mainly the same for 3 different StringIdentifierGenerators.
> >
> > Proposal: Since we have a lot more StringIdentifierGenrators (e.g. the
> > UUIDIdentifierGenerators a StringIdentifiers too), I would refactore this 3
> > classes into a wrapper in a separate package o.a.c.id.wrapper and delegate

> > to an arbitrary StringIdentifierGenerator implementation:
> >
> > class PrefixStringIdentifierGenerator implements StringIdentifierGenerator {
> > PrefixStringIdentifierGenerator(StringIdentifierGenerator delegee) {
> > this.delegee = delegee;
> > }
> > ...
> > }
>
> How about a single class CompoundStringIdentifierGenerator that can use
> the delegate as any one of prefix, middle, postfix?
>

+1 - I think we discussed something like this before.  More generally,
we could support arbitrary concatenations using an API like
o.a.c.Collections.ChainedTransformer


>
> And may I add
>
> 10/ Serial generators implement Serializable?

+1

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [id] Review before 1.0 (Summary)

[Michael Heuer]

J?rg Schaible wrote:

> 8/ Prefix generators
>
> We have 3 generators, that add a prefix to the generated id. All 3 classes
> to mainly the same for 3 different StringIdentifierGenerators.
>
> Proposal: Since we have a lot more StringIdentifierGenrators (e.g. the
> UUIDIdentifierGenerators a StringIdentifiers too), I would refactore this 3
> classes into a wrapper in a separate package o.a.c.id.wrapper and delegate
> to an arbitrary StringIdentifierGenerator implementation:
>
> class PrefixStringIdentifierGenerator implements StringIdentifierGenerator {
> PrefixStringIdentifierGenerator(StringIdentifierGenerator delegee) {
> this.delegee = delegee;
> }
> ...
> }

How about a single class CompoundStringIdentifierGenerator that can use
the delegate as any one of prefix, middle, postfix?


And may I add

10/ Serial generators implement Serializable?

   michael


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [id] Review before 1.0 (Summary)

[Phil Steitz]

>
> For me the question is, does a normal user really care about the specifics
> of an unique id. The most difference is the returned type of the id,
> because that may impact other parts of the code (e.g. DB).

I think many apps will care about more than just the type as in string
or numeric, though I agree that the need for multiple different types
in one application will be rare.  Some applications will want the id
to be random, even "secure" (e.g. session ids), some will want
sequential ids, etc.  So I think the different types are significant.
The real questions are  a) do we care to make different
implementations within type pluggable and b) do we want to provide
static methods that get ids of the different types directly as a
convenience.  Answer to a) is probably leave it to the user and b) is
it is nice to have, but again gets unweildy with too many generators. 
So, I guess I am in favor of simplifying down to just providing the
implementations - no factory, no utils class.



>
> > One thing that I would like for us to consider is to omit the uuid
> > generators from 1.0.  There is a lot to do to get that package into
> > releaseable state, including spec compliance review, and I am a little
> > concerned with our ability to support it once released, as the
> > original developer is no longer working on this code.
>
> Uuuh! Cough! Bummer! When I look into the answers given to a lot of users
> over the last two years, they were always told, c-id is stable and
> reliable, we need just to close the minor issues left in Bugzilla and
> clean-up the docs.

I don't ever recall anyone using the terms "stable" or "reliable" in
reference to the UUID code.  The code from [lang] is certainly stable.
 I did respond to one inquiry with the statement that "The main thing
standing in the
way of promotion to commons proper and a release is review and validation of
the UUID code. "  The "review and validation" (against the spec) of
the UUID code is a lot of work, as you can see.

> I know quite some projects that use a snapshot of c-id
> to generate UUIDs in production (including some of mine).

I don't know what we can do to make it more clear that people should
*not* depend on code in the commons sandbox, or any unreleased
snapshots.

> And look into
> Bugzilla. We had not much issues about UUID and the last open one can be
> easily solved by different implementations for the state. My issue list
> targetted this area anyway (concerning Exception handling and the state
> problem in this area).

Again, the issue is validating the code and verifying spec compliance.

>
> > I would be +1
> > to cleaning up the rest of the package, promoting to proper and
> > releasing a simple 1.0 without the uuid generators.  I think the
> > package is quite useful without the uuid functions and if there is
> > sufficient community interest and support we can add the uuid stuff
> > into a 1.1.
>
> Fact is, that UUIDs are part of c-id now for exactly two years and despite
> the fact, that c-id had no proper release, they are already used. Even I
> cannot use c-id-1.0, if it is without UUID support ... :-/

This is a do-ocracy, so if you are willing to do the work to get all
of the UUID code into releasable state and verify compliance against
the spec, I am +1 to push forward.  I just thought that we could get
promotion and a release out faster if we omitted this package from the
1.0 plan.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [exec] API sketch?

[Niklas Gustavsson]

Hi

Brett Porter wrote:

Hi,

Back in September 05 (wow, is it really 2006 already? :) Jerome sent a
comprehensive vision for exec. I found myself agreeing with most
everything in there (I'll reply to a couple of specifics shortly).

Message ID from then: <[EMAIL PROTECTED]>

However, it was long and wordy. I think the key part was that "we should
have a minimal exposed API". Maybe a good step forward is to sketch that
API, then write implementations that reuse existing code, then refactor
code behind the scenes later?

With this, we could get something up and working *reasonably* quickly
that is *reasonably* stable.

Jerome, Niklas, Trygve - anyone interested in picking this up? In some
ways the above email described it and this is just an interface sketch.


I think getting a very clear and simple API working would be an 
excellent next step. Given such an API, we can refactor Execute and Exec 
to fit the API. Here's a quick stab at a first proposal for a new 
Execute class:


/*
 * StreamHandlers are used for providing input,
 * retriving the output. Also used for logging.
 */
StreamHandler getStreamHandler();
void setStreamHandler(StreamHandler streamHandler);

/*
 * Watchdog is used to kill of processes running,
 * typically, to long time.
 */
ExecuteWatchdog getWatchdog();
void setWatchdog(ExecuteWatchdog watchDog);

File getWorkingDirectory();
void setWorkingDirectory(File dir);

/*
 * Methods for starting synchronous execution.
 * Returns process exit value
 */
int execute(String[] command) throws ExecuteException;
int execute(String[] command, Map environment) throws ExecuteException;

/*
 * Methods for starting asynchronous execution. Result provided to 
callback handler

 */
void execute(String[] command, ExecuteResultHandler handler) throws 
ExecuteException;
void execute(String[] command, Map environment, ExecuteResultHandler 
handler) throws ExecuteException;


Besides this API, I think we should provide utility classes for 
retrieving the current Environment. I also think we should get rid of 
the current environment classes and use a Map instead. This simplifies 
working with our API and gets us inline with the Java 1.5 environment 
support.


/niklas

---
Niklas Gustavsson
http://www.protocol7.com
mailto:[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [id] Review before 1.0 (Summary)

[Jörg Schaible]

Hi fellows,

two of the issues have already be solved (see inline comments), but I have
two new ones, see at the bottom.

Jörg Schaible wrote:

[snip]

> 3/ xxxStateImpl classes
> 
> The javadoc of ReadOnlyResourceStateImpl implies that the implementation
> tries to discover (well, use c-discovery) to load a file "uuid-[n].conf".
> In reality it expects a system property (wrong name documented) set to a
> file name that can be loaded as resource. All unit tests use a file
> "uuid1.state", that is only available during the tests.
> 
> I am just wondering, if a default is simply missing or left by intension.

This one is answered by the UUID doc of c-id.
 
> Also the derived ReadWriteFileStateImpl tries to write into the URL of the
> resource ... which will fail badly if the file is within a jar.

This part is addressed in the only current open Bugzilla issue with a
comment from Tim.

[snip]

> 5/ Unit tests
> 
> A lot of unit tests in the c-id package have own suite methods and set an
> own name for the test. While there are situations, where the usage of a
> suite can be necessary, here it is definitely not. This not only results
> in an inconsistent unit test report, but also prevents, that e.g. in
> Eclipse I can simply double click the test to get to the appropriate code.
> 
> Proposal: Remove unnecessary suite methods and TestCase ctors taking a
> name.

Phil agreed on this in private mail. Done.

[snip]


8/ Prefix generators

We have 3 generators, that add a prefix to the generated id. All 3 classes
to mainly the same for 3 different StringIdentifierGenerators.

Proposal: Since we have a lot more StringIdentifierGenrators (e.g. the
UUIDIdentifierGenerators a StringIdentifiers too), I would refactore this 3
classes into a wrapper in a separate package o.a.c.id.wrapper and delegate
to an arbitrary StringIdentifierGenerator implementation:

class PrefixStringIdentifierGenerator implements StringIdentifierGenerator {
PrefixStringIdentifierGenerator(StringIdentifierGenerator delegee) {
this.delegee = delegee;
}
...
}

9/ Wrappable genrators

The generators in the o.a.id.serial package generate ids in a sequence. A
lot of them can start over if the maximum value is reached based on the
"wrap" flag.

Proposal: Introduce a Wrappable interface, that is already implemented by
those ones:

interface Wrappable {
boolean isWrapping();
void setWrap(boolean wrap);
}



Comments?

- Jörg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r369112 - in /jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id: ./ uuid/ uuid/clock/ uuid/state/

[joehni]

Author: joehni
Date: Sat Jan 14 15:05:45 2006
New Revision: 369112

URL: http://svn.apache.org/viewcvs?rev=369112&view=rev
Log:
Clean-up unit test initialization.

Modified:

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/IdentifierGeneratorFactoryTest.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/IdentifierUtilsTest.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/uuid/NodeManagerImplTest.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/uuid/UUIDTest.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/uuid/clock/SystemClockImplTest.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/uuid/clock/ThreadClockImplTest.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/uuid/state/InMemoryStateImplTest.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/uuid/state/NodeTest.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/uuid/state/ReadOnlyResourceStateImplTest.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/uuid/state/ReadWriteFileStateImplTest.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/uuid/state/StateHelperTest.java

Modified: 
jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/IdentifierGeneratorFactoryTest.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/IdentifierGeneratorFactoryTest.java?rev=369112&r1=369111&r2=369112&view=diff
==
--- 
jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/IdentifierGeneratorFactoryTest.java
 (original)
+++ 
jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/IdentifierGeneratorFactoryTest.java
 Sat Jan 14 15:05:45 2006
@@ -1,5 +1,5 @@
 /*
- * Copyright 2003-2004 The Apache Software Foundation.
+ * Copyright 2003-2006 The Apache Software Foundation.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -15,10 +15,7 @@
  */
 package org.apache.commons.id;
 
-import junit.framework.Test;
 import junit.framework.TestCase;
-import junit.framework.TestSuite;
-import junit.textui.TestRunner;
 
 /**
  * Unit tests for [EMAIL PROTECTED] IdentifierGeneratorFactory}.
@@ -28,25 +25,6 @@
  */
 public class IdentifierGeneratorFactoryTest extends TestCase {
 
-/** Constructor @param name String of the test. */
-public IdentifierGeneratorFactoryTest(String name) {
-super(name);
-}
-
-/** Main application entry @param args String array of argument. */
-public static void main(String[] args) {
-TestRunner.run(suite());
-}
-
-/** @see junit.framework.TestSuite#suite() */
-public static Test suite() {
-TestSuite suite = new TestSuite(IdentifierGeneratorFactoryTest.class);
-suite.setName("IdentifierGeneratorFactory Tests");
-return suite;
-}
-
-//-
-/** @see junit.framework.TestSuite#setUp() */
 protected void setUp() throws Exception {
 super.setUp();
 }

Modified: 
jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/IdentifierUtilsTest.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/IdentifierUtilsTest.java?rev=369112&r1=369111&r2=369112&view=diff
==
--- 
jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/IdentifierUtilsTest.java
 (original)
+++ 
jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/IdentifierUtilsTest.java
 Sat Jan 14 15:05:45 2006
@@ -15,13 +15,11 @@
  */
 package org.apache.commons.id;
 
+import junit.framework.AssertionFailedError;
+
 import java.lang.reflect.Constructor;
 import java.lang.reflect.Modifier;
 
-import junit.framework.AssertionFailedError;
-import junit.framework.Test;
-import junit.framework.TestSuite;
-
 /**
  * Tests the org.apache.commons.id.IdentifierUtils class.
  *
@@ -30,17 +28,6 @@
  */
 public class IdentifierUtilsTest extends junit.framework.TestCase {
 
-/** Constructor @param name String test name. */
-public IdentifierUtilsTest(String name) {
-super(name);
-}
-
-/** @see junit.framework.TestSuite#suite() */
-public static Test suite() {
-TestSuite suite = new TestSuite(IdentifierUtilsTest.class);
-suite.setName("IdentifierUtils Tests");
-return suite;
-}
 
 /** Factory instance */
 protected static IdentifierGeneratorFactory factory = 
IdentifierGeneratorFactory.newInstance();

Modified: 
jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/uuid/NodeManagerImplTest.java
URL: 
http://svn.apache.org/viewcvs/jakarta/comm

[scxml] a few observations, issues before release

[Tim OBrien]

I'm interested in the SCXML codebase, but before I could vote +1 for promotion, 
I'm generally
thinking that the following issues need to be discussed.  I apologize if this 
is blocking RDC.

1. SCXMLSerializer 

Right now the code to serialize an SCXML object is a Visitor pattern that 
constructs XML using a
series of StringBuffers.  The code to read this XML document alrady uses a 
straightforward set of
Digester rules and the project already depends on commons-digester.

*Alternative: Add a dependency to commons-betwixt, map the model package to 
XML.  Instead of
writing Digester rules for reading and constructing Strings for writing, use 
the betwixt mapping
files as a single point of translation.

The current SCXMLDigester isn't trivial by any means, but I think it would be 
easy to implement
the external source rule.  The current SCXMLDigester plays two roles, first it 
sets up the
Digester rules and "Digests" the XML, but it also does a bit of post-processing 
in updateSCXML.  I
think the component would be well served to separate everything that has to do 
with serialization
to/from XML into a separate package and to move some of this postProcess that 
happens in
updateSCXML somewhere else.

2. Decouple Execution Context from the SCXML Model

Right now, the Context passed into the class that parses the XML and creates 
the SCXML object is
the global execution context.  You pass in a JexlContext when you are parsing 
the SCXML model, it
is assigned to all of the State objects.

So, bear with me, assume I have a SCXML document that represents the valid 
states of a stopwatch
(ready, running, paused, stopped).  The SCXML models the watch in a way similar 
to the microwave
sample in the Working Draft, it uses a reference to a "timer" variable.  To do 
this with the
current implementation of SCXML, I would need to do the following twice 
(assuming a JexlContext):

  a. Create a JexlContext
  b. Populate the JexlContext with the appropriate variables
  c. Call SCXMLDigester passing in the JexlEvaluator and the JexlContext I want 
to execute this
state machine with
  d. Create an instance of SCXMLExecutor, pass it the SCXML from step c.

For each watch I need to model in this application, the implementation forces 
me to parse that
SCXML document with Digester every time I want to model a separate StopWatch.  
In the application
I'm interested in using this in, hundreds of documents in a content management 
system are going to
be modeled as individual state machines, I would hate to have to parse an SCXML 
file for each
individual document.

* Alternative: Provide a mechanism that allows you to clone an SCXML  instance 
so that you can
create a separate SCXMLExecutor that can model the same statemachine with an 
isolated Context.

* Better Alternative: States do not "have" a context.  Take the context 
property off of the State
and change executeActionList in SCXMLSemanticsImpl to get the Context from the 
Executor.  
Likewise, Transitions do not have a "notificationRegistry", take that property 
off of a transition
and just have the SCXMLSemanticsImpl get the notificationRegistry from the 
Executor.

I don't think this is a terribly difficult idea, and decoupling the description 
of the FSM from
the execution state, would also make it much easier to persist either one.  

3. Is SCXML appropriate for Commons? 

Commons SCXML might not be appropriate for Jakarta Commons.  See the recent 
discussion on general@
about componentizing different parts of Jakarta.  I'm not going to fight this 
one because I think
we're in a time of transition, but commons-scxml might ultimately benefit from 
producing a number
of separate artifacts.  scxml, scxml-faces, scxml-shale, etc.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r369108 - in /jakarta/commons/sandbox/id/trunk: ./ src/java/org/apache/commons/id/ src/java/org/apache/commons/id/random/ src/java/org/apache/commons/id/serial/ src/test/org/apache/commons

[joehni]

Author: joehni
Date: Sat Jan 14 14:56:43 2006
New Revision: 369108

URL: http://svn.apache.org/viewcvs?rev=369108&view=rev
Log:
Start to clean-up javadoc.

Modified:
jakarta/commons/sandbox/id/trunk/project.xml

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/AbstractLongIdentifierGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/AbstractStringIdentifierGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/IdentifierGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/IdentifierGeneratorFactory.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/LongIdentifierGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/StringIdentifierGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/random/SessionIdGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/serial/AlphanumericGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/serial/LongGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/serial/NumericGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/serial/PrefixedAlphanumericGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/serial/PrefixedLeftPaddedNumericGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/serial/PrefixedNumericGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/serial/TimeBasedAlphanumericIdentifierGenerator.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/serial/PrefixedAlphanumericGeneratorTest.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/serial/PrefixedLeftPaddedNumericGeneratorTest.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/serial/PrefixedNumericGeneratorTest.java

Modified: jakarta/commons/sandbox/id/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/project.xml?rev=369108&r1=369107&r2=369108&view=diff
==
--- jakarta/commons/sandbox/id/trunk/project.xml (original)
+++ jakarta/commons/sandbox/id/trunk/project.xml Sat Jan 14 14:56:43 2006
@@ -135,11 +135,12 @@
   
 
   
-
+
 
   commons-discovery
   0.2
 
+
 
   commons-logging
   1.0.3

Modified: 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/AbstractLongIdentifierGenerator.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/AbstractLongIdentifierGenerator.java?rev=369108&r1=369107&r2=369108&view=diff
==
--- 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/AbstractLongIdentifierGenerator.java
 (original)
+++ 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/AbstractLongIdentifierGenerator.java
 Sat Jan 14 14:56:43 2006
@@ -1,5 +1,5 @@
 /*
- * Copyright 2003-2004 The Apache Software Foundation.
+ * Copyright 2003-2006 The Apache Software Foundation.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -16,7 +16,7 @@
 package org.apache.commons.id;
 
 /**
- * Abstract superclass for LongIdentifierGenerator implementations.
+ * Abstract superclass for LongIdentifierGenerator implementations.
  *
  * @author Commons-Id team
  * @version $Id$
@@ -24,51 +24,41 @@
 public abstract class AbstractLongIdentifierGenerator implements 
LongIdentifierGenerator {
 
 /**
- * Constructor
+ * Constructor.
  */
 protected AbstractLongIdentifierGenerator() {
 super();
 }
 
 /**
- *  Returns the maximum value for an identifier from this generator.
+ * Returns the maximum value of an identifier from this generator.
  *
  * The default implementation returns Long.MAX_VALUE. Implementations
  * whose identifiers are bounded below Long.MAX_VALUE should override this 
method to
  * return the maximum value of a generated identifier.
  *
- * @return the maximum identifier value
+ * @return [EMAIL PROTECTED]
  */
 public long maxValue() {
 return Long.MAX_VALUE;
 }
 
 /**
- *  Returns the minumum value for an identifier from this generator.
+ * Returns the minimum value of an identifier from this generator.
  *
  * The default implementation returns Long.MIN_VALUE. Implementations
  * whose identifiers are bounded above Long.MIN_VALUE should override this 
method to
  * return the minimum value of a generated identifier.
  *
- * @return the minimum identifier value
+ * @return [EMAIL PROTECTED]
  */
 public long mi

Re: [id] Review before 1.0 (Summary)

[Jörg Schaible]

Hi Stephen,

Stephen Colebourne wrote:

> Tim OBrien wrote:
>> --- Jörg Schaible <[EMAIL PROTECTED]> wrote:
>>>4/ Copied c-codec classes in official API
>>>
>>>To remove a dependency to c-codec the digest and hex utilities have been
>>>copied to c-id, but they are now publicly available in the o.a.c.id
>>>namespace.

[snip]
 
>> +1 with moving into an internal package with a package.html,
> 
> I strongly prefer using package scope if at all possible, and
> referencing the svn revision id that the code was copied from.

Well, there's no problem in creating a copy with svn from the current code
code, but this does not affect the removal of unused code in the copy. A
later 3-way-merge can update the remaining code always. Concerning package
scope I will have to take a closer look, since the functionality is used in
two c-id packages.

- Jörg



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [id] Review before 1.0 (Summary)

[Jörg Schaible]

Hi Stephen,

Stephen Colebourne wrote:

> As per the general thrust of Phil's mail, we should remove everything
> thats complex and not working and get a simple 1.0 out there. We can
> then grow from that point as and when the desire arises.

As answered to Phil, UUID is now part of c-id for two years and already used
in production. Nobody can guarantee for error-free code here anyway, but
all current issues with the code are not related to the algorithms, but to
exception handling and managing the internal (persistent) state of the
generator. This is not *that* problematic to clean it up.

[snip]

- Jörg



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [id] Review before 1.0 (Summary)

[Jörg Schaible]

Hi Phil,

comments in line again ...

Phil Steitz wrote:

> On 1/14/06, Jörg Schaible <[EMAIL PROTECTED]> wrote:
>> Hi folks,
>>
>> reviewing c-id I found more issues to resolve before releasing 1.0 final.
>> Since I already reported different complaints, I create here a summary of
>> anything already reported and all new issues.
>>
>> 1/ Concept of IdentifierGeneratorFactory
>>
>> The IdentifierGeneratorFactory provides a easy-to-use concept for casual
>> use of id generators. Three elements are part of it:
>>
>> abstract class IdentifierGeneratorFactory - defines the generator types
>> class DefaultIdentifierGeneratorFactory - delivers implementations
>> class IdentifierUtils - easy id generation using the default factory
>>
>> the basic idea is, that a user can implement an own factory and provide
>> it with a system factory and it is automatically used as default in the
>> IdentifierUtils - so far so good.
>>
>> The bad part in the concept is, that we have a variety of generator
>> implementations and all of them are quite different in their
>> initialization. Therefore has the IdentifierGeneratorFactory not only
>> three simple methods to generate the default generator for each
>> (currently supported) id type (String, Long and UUID), but has a variety
>> of methods tailored exactly for the ctors of the different generator
>> implementations, which makes this "factory" quite obscure.
>>
> Agreed.  This is a consequence of the growth in the number of
> different generator types.
> 
>> Modifying a class with every new implementations is for me a kind of
>> "code smell". And the current code already gives evidence of this, since
>> we have new generator implementations, that cannot be
>> accessed/initialized with the factory. Additionally some methods have
>> been added to support newer generator implementations, but the
>> appropriate methods to make use of the generated ids are missing in the
>> IdentifierUtils.
>>
> Agreed again.  The idea was to allow pluggable implemenations of the
> different generator types, but as the number of types increases, this
> gets unweildy.
> 
>> So we either complete those 3 classes for all generator implementations
>> or tailor them to a useful subset for the casual user:
>>
>> interface IdentifierGeneratorFactory {
>> LongIdentifierGenerator longIDentifierGenerator();
>> StringIdentifierGenerator stringIDentifierGenerator();
>> UUIDIdentifierGenerator uuidIDentifierGenerator();
>> }
> 
> But then you lose the distinction among the different subtypes. The 
> question is, do we care about making the implementation of, say
> prefixAlphanumericGenerator pluggable (i.e., would anyone ever really
> want to provide a different factory implementation that returned a
> generator different from PrefixAlphaNumericGenerator from the one we
> provide?  And if so, is the current setup the best way to support
> that.  Answer is likely "no" to at least the second question.

For me the question is, does a normal user really care about the specifics
of an unique id. The most difference is the returned type of the id,
because that may impact other parts of the code (e.g. DB). If we provide a
sensible default for each type, it might be enough. And then it is really
simple for everyone to provide a different generator for each of the types.

>> The question is, if a user *normally* requires in one application
>> different
>> UUID genenerators, string generators or long generators?  In all special
>> cases the generator instance can be generated directly or by an
>> appropriate environment (standard use case in IoC containers, where the
>> implementation and their initialization is configured anyway).
>>
>> Proposal: Use as default a VersionFourGenerator, SessionIdGenerator and
>> LongGenerator. If he has the need for a different generator or a
>> different initialization, he can still provide easily an own factory and
>> set the system property.
> 
> It might actually be better to dispense with
> IdentifierGeneratorFactory altogether, leaving the utils class in
> place, but having it directly instantiate provided impls.

Well - as pico guy - the factory is for me some kind of poor man's IoC
approach, but it might have a place if it is much simpler. But even for the
utils class the argumentation is similar: Do we need a static instance for
every generator type and their different initializations and an accessor
method for each nextIdentifier() method? You have the same problem here:
Add a new generator implementation and you have to add one or more
appropriate methods and static instances to the utils class. Use the "type"
approach from above and you have 3 instances with 3 methods accessing the
specified factory.

> This would 
> also allow us to drop the [discovery] dependency (with some additional
> work on uuid if we decidt to include this in the release - see below).

See also below ...

[snip issues 2-7 for which I hope also to receive some comments one time
]

Re: [id] Review before 1.0 (Summary)

[Stephen Colebourne]

As per the general thrust of Phil's mail, we should remove everything 
thats complex and not working and get a simple 1.0 out there. We can 
then grow from that point as and when the desire arises.


Stephen


Phil Steitz wrote:

On 1/14/06, Jörg Schaible <[EMAIL PROTECTED]> wrote:


Hi folks,

reviewing c-id I found more issues to resolve before releasing 1.0 final.
Since I already reported different complaints, I create here a summary of
anything already reported and all new issues.

1/ Concept of IdentifierGeneratorFactory

The IdentifierGeneratorFactory provides a easy-to-use concept for casual use
of id generators. Three elements are part of it:

abstract class IdentifierGeneratorFactory - defines the generator types
class DefaultIdentifierGeneratorFactory - delivers implementations
class IdentifierUtils - easy id generation using the default factory

the basic idea is, that a user can implement an own factory and provide it
with a system factory and it is automatically used as default in the
IdentifierUtils - so far so good.

The bad part in the concept is, that we have a variety of generator
implementations and all of them are quite different in their
initialization. Therefore has the IdentifierGeneratorFactory not only three
simple methods to generate the default generator for each (currently
supported) id type (String, Long and UUID), but has a variety of methods
tailored exactly for the ctors of the different generator implementations,
which makes this "factory" quite obscure.



Agreed.  This is a consequence of the growth in the number of
different generator types.



Modifying a class with every new implementations is for me a kind of "code
smell". And the current code already gives evidence of this, since we have
new generator implementations, that cannot be accessed/initialized with the
factory. Additionally some methods have been added to support newer
generator implementations, but the appropriate methods to make use of the
generated ids are missing in the IdentifierUtils.



Agreed again.  The idea was to allow pluggable implemenations of the
different generator types, but as the number of types increases, this
gets unweildy.



So we either complete those 3 classes for all generator implementations or
tailor them to a useful subset for the casual user:

interface IdentifierGeneratorFactory {
   LongIdentifierGenerator longIDentifierGenerator();
   StringIdentifierGenerator stringIDentifierGenerator();
   UUIDIdentifierGenerator uuidIDentifierGenerator();
}



But then you lose the distinction among the different subtypes.  The
question is, do we care about making the implementation of, say
prefixAlphanumericGenerator pluggable (i.e., would anyone ever really
want to provide a different factory implementation that returned a
generator different from PrefixAlphaNumericGenerator from the one we
provide?  And if so, is the current setup the best way to support
that.  Answer is likely "no" to at least the second question.


The question is, if a user *normally* requires in one application different
UUID genenerators, string generators or long generators?  In all special
cases the generator instance can be generated directly or by an appropriate
environment (standard use case in IoC containers, where the implementation
and their initialization is configured anyway).

Proposal: Use as default a VersionFourGenerator, SessionIdGenerator and
LongGenerator. If he has the need for a different generator or a different
initialization, he can still provide easily an own factory and set the
system property.



It might actually be better to dispense with
IdentifierGeneratorFactory altogether, leaving the utils class in
place, but having it directly instantiate provided impls.  This would
also allow us to drop the [discovery] dependency (with some additional
work on uuid if we decidt to include this in the release - see below).


2/ Exception handling for UUID 1 generator state

Currently c-id cannot be compiled with JDK 1.3, since it uses the ctor of
the RuntimeException with a causing Throwable. While this can easily
removed, the concepts leading to the situation must be reconsidered.

The UUID1 generation supports several implementations to persist the state
of such an generator. The State interface has a load and store method that
throw both just an arbitrary Exception, mainly because the underlying
implementation may have any kind of problems reading or storing the state
(XML parser, IO, DB, ...). The funny part is, that such an exception is
wrapped by the RuntimeEx from above and from the user's PoV he might get a
bad surprise calling nextIdentifier() on a UUID 1 generator ...

Proposal: Introduce a StatePerstistenceException derived from RTEx, that
might be thrown from the State implementations and document this at the
proper places in javadoc.

3/ xxxStateImpl classes

The javadoc of ReadOnlyResourceStateImpl implies that the implementation
tries to discover (well, use c-discovery) to

Re: [id] Review before 1.0 (Summary)

[Phil Steitz]

On 1/14/06, Jörg Schaible <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> reviewing c-id I found more issues to resolve before releasing 1.0 final.
> Since I already reported different complaints, I create here a summary of
> anything already reported and all new issues.
>
> 1/ Concept of IdentifierGeneratorFactory
>
> The IdentifierGeneratorFactory provides a easy-to-use concept for casual use
> of id generators. Three elements are part of it:
>
> abstract class IdentifierGeneratorFactory - defines the generator types
> class DefaultIdentifierGeneratorFactory - delivers implementations
> class IdentifierUtils - easy id generation using the default factory
>
> the basic idea is, that a user can implement an own factory and provide it
> with a system factory and it is automatically used as default in the
> IdentifierUtils - so far so good.
>
> The bad part in the concept is, that we have a variety of generator
> implementations and all of them are quite different in their
> initialization. Therefore has the IdentifierGeneratorFactory not only three
> simple methods to generate the default generator for each (currently
> supported) id type (String, Long and UUID), but has a variety of methods
> tailored exactly for the ctors of the different generator implementations,
> which makes this "factory" quite obscure.
>
Agreed.  This is a consequence of the growth in the number of
different generator types.

> Modifying a class with every new implementations is for me a kind of "code
> smell". And the current code already gives evidence of this, since we have
> new generator implementations, that cannot be accessed/initialized with the
> factory. Additionally some methods have been added to support newer
> generator implementations, but the appropriate methods to make use of the
> generated ids are missing in the IdentifierUtils.
>
Agreed again.  The idea was to allow pluggable implemenations of the
different generator types, but as the number of types increases, this
gets unweildy.

> So we either complete those 3 classes for all generator implementations or
> tailor them to a useful subset for the casual user:
>
> interface IdentifierGeneratorFactory {
> LongIdentifierGenerator longIDentifierGenerator();
> StringIdentifierGenerator stringIDentifierGenerator();
> UUIDIdentifierGenerator uuidIDentifierGenerator();
> }

But then you lose the distinction among the different subtypes.  The
question is, do we care about making the implementation of, say
prefixAlphanumericGenerator pluggable (i.e., would anyone ever really
want to provide a different factory implementation that returned a
generator different from PrefixAlphaNumericGenerator from the one we
provide?  And if so, is the current setup the best way to support
that.  Answer is likely "no" to at least the second question.
>
> The question is, if a user *normally* requires in one application different
> UUID genenerators, string generators or long generators?  In all special
> cases the generator instance can be generated directly or by an appropriate
> environment (standard use case in IoC containers, where the implementation
> and their initialization is configured anyway).
>
> Proposal: Use as default a VersionFourGenerator, SessionIdGenerator and
> LongGenerator. If he has the need for a different generator or a different
> initialization, he can still provide easily an own factory and set the
> system property.

It might actually be better to dispense with
IdentifierGeneratorFactory altogether, leaving the utils class in
place, but having it directly instantiate provided impls.  This would
also allow us to drop the [discovery] dependency (with some additional
work on uuid if we decidt to include this in the release - see below).
>
> 2/ Exception handling for UUID 1 generator state
>
> Currently c-id cannot be compiled with JDK 1.3, since it uses the ctor of
> the RuntimeException with a causing Throwable. While this can easily
> removed, the concepts leading to the situation must be reconsidered.
>
> The UUID1 generation supports several implementations to persist the state
> of such an generator. The State interface has a load and store method that
> throw both just an arbitrary Exception, mainly because the underlying
> implementation may have any kind of problems reading or storing the state
> (XML parser, IO, DB, ...). The funny part is, that such an exception is
> wrapped by the RuntimeEx from above and from the user's PoV he might get a
> bad surprise calling nextIdentifier() on a UUID 1 generator ...
>
> Proposal: Introduce a StatePerstistenceException derived from RTEx, that
> might be thrown from the State implementations and document this at the
> proper places in javadoc.
>
> 3/ xxxStateImpl classes
>
> The javadoc of ReadOnlyResourceStateImpl implies that the implementation
> tries to discover (well, use c-discovery) to load a file "uuid-[n].conf".
> In reality it expects a system property (wrong name documented) set to a
> f

Re: [vote] access for Niklas Gustavsson to the sandbox

[Phil Steitz]

+1
Phil
On 1/14/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> +1
>
> - robert
>
> On Fri, 2006-01-13 at 10:18 +1100, Brett Porter wrote:
> > Hi,
> >
> > I know the sandbox is meant to be open to any committers on request, but
> > Niklas is a recent addition to an incubator project, so I thought it is
> > best to double check with a vote.
> >
> > Niklas contributed the original Ant refactoring to start commons-exec,
> > and has some outstanding patches that I haven't had time to review and
> > apply yet. I suspect I'm getting in his way right now.
> >
> > I'd like to grant him access to commit to the sandbox so he can improve
> > and document exec. I think at this point this is essential to give it
> > some momentum. Plenty of people are interested, but they need to be able
> > to use it first :)
> >
> > I can still do lazy review and discuss the design on the list.
> >
> > +1 from me.
> >
> > - Brett
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQBDyPnN1TNOdbExPeIRAutqAJ0Zkn9X6xLgkTI9WtkkLiLDSZgH8wCfXq+X
> im2ouVlXwTdge7T/KNSiDpE=
> =otIh
> -END PGP SIGNATURE-
>
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: clirr

[Phil Steitz]

I had same experience as Stephen; though I did get it to work at one
point in m1 by setting build properties and some googling and hocus
pocus to get the right clirr plugin jar installed. Sorry, but I just
lost the drive where I had that all set up, so can't provide details
atm.

In any case, I agree that we should in general run both jdiff and
clirr reports prior to .x releases for commons components.  These can
be run from ant or the command line if necessary.  I am not sure if
the m2 plugins for exist yet, but we should include how-to for this in
the revision of the release instructions for m2.

Phil

On 1/14/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> I think I had to use ant to run it last as the maven plugin didn't work
> for me. YMMV
>
> Stephen
>
>
> Torsten Curdt wrote:
> > Guys,
> >
> > anyone using clirr through maven? I would like to have
> > it done (be)for(e) the BCEL release. But it would probably
> > also make sense for the commons projects.
> >
> > cheers
> > --
> > Torsten
>
> -
> 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]

DO NOT REPLY [Bug 38145] - [io] Fix CheckStyle Issues

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38145


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-01-14 19:24 ---
Patch applied, thanks
(I'm happy for you to apply things yourself!)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r369075 - in /jakarta/commons/proper/io/trunk: ./ src/java/org/apache/commons/io/ src/java/org/apache/commons/io/filefilter/ src/java/org/apache/commons/io/input/ src/java/org/apache/commo

[scolebourne]

Author: scolebourne
Date: Sat Jan 14 10:23:42 2006
New Revision: 369075

URL: http://svn.apache.org/viewcvs?rev=369075&view=rev
Log:
Fix checkstyle errors
bug 38145, from Niall Pemberton

Modified:
jakarta/commons/proper/io/trunk/checkstyle.xml
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/HexDump.java

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/AgeFileFilter.java

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/ClassLoaderObjectInputStream.java

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/ByteArrayOutputStream.java

Modified: jakarta/commons/proper/io/trunk/checkstyle.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/checkstyle.xml?rev=369075&r1=369074&r2=369075&view=diff
==
--- jakarta/commons/proper/io/trunk/checkstyle.xml (original)
+++ jakarta/commons/proper/io/trunk/checkstyle.xml Sat Jan 14 10:23:42 2006
@@ -31,6 +31,7 @@
 
 
   
+  
 
 
   

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/HexDump.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/HexDump.java?rev=369075&r1=369074&r2=369075&view=diff
==
--- jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/HexDump.java 
(original)
+++ jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/HexDump.java 
Sat Jan 14 10:23:42 2006
@@ -1,5 +1,5 @@
 /*
- * Copyright 2002,2004-2005 The Apache Software Foundation.
+ * Copyright 2002,2004-2006 The Apache Software Foundation.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -42,9 +42,9 @@
 /**
  * Dump an array of bytes to an OutputStream.
  *
- * @param data the byte array to be dumped
- * @param offset its offset, whatever that might mean
- * @param stream the OutputStream to which the data is to be
+ * @param data  the byte array to be dumped
+ * @param offset  its offset, whatever that might mean
+ * @param stream  the OutputStream to which the data is to be
  *   written
  * @param index initial index into the byte array
  *
@@ -118,6 +118,12 @@
 28, 24, 20, 16, 12, 8, 4, 0
 };
 
+/**
+ * Dump a long value into a StringBuffer.
+ *
+ * @param value  the long value to be dumped
+ * @return StringBuffer containing the dumped value.
+ */
 private static StringBuffer dump(long value) {
 _lbuffer.setLength(0);
 for (int j = 0; j < 8; j++) {
@@ -127,6 +133,12 @@
 return _lbuffer;
 }
 
+/**
+ * Dump a byte value into a StringBuffer.
+ *
+ * @param value  the byte value to be dumped
+ * @return StringBuffer containing the dumped value.
+ */
 private static StringBuffer dump(byte value) {
 _cbuffer.setLength(0);
 for (int j = 0; j < 2; j++) {
@@ -134,4 +146,5 @@
 }
 return _cbuffer;
 }
+
 }

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/AgeFileFilter.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/AgeFileFilter.java?rev=369075&r1=369074&r2=369075&view=diff
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/AgeFileFilter.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/AgeFileFilter.java
 Sat Jan 14 10:23:42 2006
@@ -50,7 +50,7 @@
 /**
  * Constructs a new age file filter for files older than a certain cutoff.
  *
- * @param age  the threshold age of the files
+ * @param cutoff  the threshold age of the files
  */
 public AgeFileFilter(long cutoff) {
 this(cutoff, true);
@@ -60,7 +60,7 @@
  * Constructs a new age file filter for files on any one side
  * of a certain cutoff.
  *
- * @param age  the threshold age of the files
+ * @param cutoff  the threshold age of the files
  * @param acceptOlder  if true, older files are accepted, else newer ones
  */
 public AgeFileFilter(long cutoff, boolean acceptOlder) {
@@ -72,7 +72,7 @@
  * Constructs a new age file filter for files older than a certain
  * cutoff date.
  *
- * @param age  the threshold age of the files
+ * @param cutoffDate  the threshold age of the files
  */
 public AgeFileFilter(Date cutoffDate) {
 this(cutoffDate, true);
@@ -82,7 +82,7 @@
  * Constructs a new age file filter for files on 

DO NOT REPLY [Bug 36315] - [io] Add recursive directory copy

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36315


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-01-14 19:15 ---
Method added, but with different implementation

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r369070 - in /jakarta/commons/proper/io/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/io/FileUtils.java src/test/org/apache/commons/io/FileUtilsTestCase.java

[scolebourne]

Author: scolebourne
Date: Sat Jan 14 10:15:16 2006
New Revision: 369070

URL: http://svn.apache.org/viewcvs?rev=369070&view=rev
Log:
New FileUtils method to copy a directory to within another directory
rfe 36315

Modified:
jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt

jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java

jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsTestCase.java

Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt?rev=369070&r1=369069&r2=369070&view=diff
==
--- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Sat Jan 14 10:15:16 2006
@@ -50,15 +50,18 @@
 
 - FileUtils.lineIterator
   IOUtils.lineIterator
-  New methods to provide an iterator over the lines in a file
+  New methods to provide an iterator over the lines in a file [38083]
+
+- FileUtils.copyDirectoryToDirectory
+  New method to copy a directory to within another directory [36315]
 
 
 Feedback
 
-Open source works best when you give feedback.
+Open source works best when you give feedback:
 http://jakarta.apache.org/commons/io/
 
-Please direct all bug reports to Bugzilla.
+Please direct all bug reports to Bugzilla (prefix bug reports by [io])
 http://issues.apache.org/bugzilla/buglist.cgi?product=Commons&component=IO
 
 Or subscribe to the commons-user mailing list (prefix emails by [io])

Modified: 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java?rev=369070&r1=369069&r2=369070&view=diff
==
--- 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java 
(original)
+++ 
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java 
Sat Jan 14 10:15:16 2006
@@ -579,12 +579,48 @@
 
 //---
 /**
+ * Copies a directory to within another directory preserving the file 
dates.
+ * 
+ * This method copies the source directory and all its contents to a
+ * directory of the same name in the specified destination directory.
+ * 
+ * The destination directory is created if it does not exist.
+ * If the destination directory did exist, then this method merges
+ * the source with the destination, with the source taking precedence.
+ *
+ * @param srcDir  an existing directory to copy, must not be null
+ * @param destDir  the directory to place the copy in, must not be null
+ *
+ * @throws NullPointerException if source or destination is null
+ * @throws IOException if source or destination is invalid
+ * @throws IOException if an IO error occurs during copying
+ */
+public static void copyDirectoryToDirectory(File srcDir, File destDir) 
throws IOException {
+if (srcDir == null) {
+throw new NullPointerException("Source must not be null");
+}
+if (srcDir.exists() && srcDir.isDirectory() == false) {
+throw new IllegalArgumentException("Source '" + destDir + "' is 
not a directory");
+}
+if (destDir == null) {
+throw new NullPointerException("Destination must not be null");
+}
+if (destDir.exists() && destDir.isDirectory() == false) {
+throw new IllegalArgumentException("Destination '" + destDir + "' 
is not a directory");
+}
+copyDirectory(srcDir, new File(destDir, srcDir.getName()), true);
+}
+
+/**
  * Copies a whole directory to a new location preserving the file dates.
  * 
  * This method copies the specified directory and all its child
  * directories and files to the specified destination.
  * The destination is the new location and name of the directory.
- * If it already exists, the contents will be overwritten.
+ * 
+ * The destination directory is created if it does not exist.
+ * If the destination directory did exist, then this method merges
+ * the source with the destination, with the source taking precedence.
  *
  * @param srcDir  an existing directory to copy, must not be null
  * @param destDir  the new directory, must not be null
@@ -603,6 +639,7 @@
  * 
  * This method copies the contents of the specified source directory
  * to within the specified destination directory.
+ * 
  * The destination directory is created if it does not exist.
  * If the destination directory did exist, then this method merges
  * the source with the destination, with the source taking precedence.

Modified: 
jakarta/commons/proper/io/trunk/

svn commit: r369069 - /jakarta/commons/proper/io/trunk/xdocs/tasks.xml

[scolebourne]

Author: scolebourne
Date: Sat Jan 14 10:14:21 2006
New Revision: 369069

URL: http://svn.apache.org/viewcvs?rev=369069&view=rev
Log:
Remove completed line iterator task

Modified:
jakarta/commons/proper/io/trunk/xdocs/tasks.xml

Modified: jakarta/commons/proper/io/trunk/xdocs/tasks.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/xdocs/tasks.xml?rev=369069&r1=369068&r2=369069&view=diff
==
--- jakarta/commons/proper/io/trunk/xdocs/tasks.xml (original)
+++ jakarta/commons/proper/io/trunk/xdocs/tasks.xml Sat Jan 14 10:14:21 2006
@@ -28,7 +28,6 @@
 A proper user guide
 A FileWriter that takes an encoding (base on 
LockableFileWriter)
 A URLUtils class that has many of the FileUtils operations, but 
for a URL
-An iterator over the lines in a file
 FilePoller for telling when a file changes. Look in Tomcat, or 
GenJava[bayard]
 A "hot folder" handler which triggers an action when a new file 
has been uploaded to an FTP directory, for example.
 JoinReader/ConcatReader. One in GenJava, one submitted to 
Bayard



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-commons Wiki] Update of "SCXML/SCXMLFaq" by TimObrien

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" 
for change notification.

The following page has been changed by TimObrien:
http://wiki.apache.org/jakarta-commons/SCXML/SCXMLFaq

--
  
  * Does Commons SCXML implement the entire Working Draft?  Are there any parts 
of the SCXML draft that are not covered by Commons SCXML?
  
+ * Is there an XML Schema associated with the SCXML Working Draft?
+ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38083] - [io][PATCH] Iterate over the lines in a file and the files in a directory

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38083


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-01-14 18:08 ---
This seems to be done now

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38130] - [io] Tests fail on Windows 2000 due to File lastModified() behaviour

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38130


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-01-14 18:00 ---
Patch applied, thanks

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-commons Wiki] Update of "SCXML/SCXMLFaq" by TimObrien

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" 
for change notification.

The following page has been changed by TimObrien:
http://wiki.apache.org/jakarta-commons/SCXML/SCXMLFaq

The comment on the change is:
Just asking a bunch of questions, ultimate inclusion in online doc..

New page:
* What is an Evaluator?

* What is a Context?

* Can I create a single instance of an Evaluator and reuse it for both the 
SCXMLDigester and the SCXMLExecutor?

* Once I set up an SCXMLExecutor (call the constructor, set the state machine) 
is there anything I have to do to "Activate" it.  In other words, do is there 
some sort of "go()" method?

* Can multiplethreads safely interact with an instance of SCXMLExecutor?  In 
other words, do I have to worry about synchronizing access to these objects?

* Can I have multiple instances of SCXMLExecutor all working off of a single 
instance of the SCXML class?  For example, if I have an SCXML that represents 
the states of a stop watch, can I have multiple instances of SCXMLExecutor 
operating off of this single SCXML instance to model many stop watches?

* Can I use SCXML in a non-voice application?

* What are the core requirements of SCXML, do I need to include the JSP and 
Servlet API or the Faces libraries?  Do I need to include Commons JEXL or 
Commons EL?

* Does Commons SCXML implement the entire Working Draft?  Are there any parts 
of the SCXML draft that are not covered by Commons SCXML?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r369049 - in /jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io: FileUtilsFileNewerTestCase.java filefilter/FileFilterTestCase.java

[scolebourne]

Author: scolebourne
Date: Sat Jan 14 08:55:58 2006
New Revision: 369049

URL: http://svn.apache.org/viewcvs?rev=369049&view=rev
Log:
Fix tests to handle last modified date behaviour on Win2k
bug 38130, from Niall Pemberton

Modified:

jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsFileNewerTestCase.java

jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java

Modified: 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsFileNewerTestCase.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsFileNewerTestCase.java?rev=369049&r1=369048&r2=369049&view=diff
==
--- 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsFileNewerTestCase.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsFileNewerTestCase.java
 Sat Jan 14 08:55:58 2006
@@ -1,5 +1,5 @@
 /*
- * Copyright 2003,2004 The Apache Software Foundation.
+ * Copyright 2003-2006 The Apache Software Foundation.
  * 
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -67,11 +67,11 @@
 throw new IllegalStateException("The m_testFile1 should exist");
 
 long fileLastModified = m_testFile1.lastModified();
-final long ONE_SECOND = 1000;
+final long TWO_SECOND = 2000;
 
-testIsFileNewer("one second earlier is not newer" , m_testFile1, 
fileLastModified + ONE_SECOND, false);
+testIsFileNewer("two second earlier is not newer" , m_testFile1, 
fileLastModified + TWO_SECOND, false);
 testIsFileNewer("same time is not newer" , m_testFile1, 
fileLastModified, false);
-testIsFileNewer("one second later is newer" , m_testFile1, 
fileLastModified - ONE_SECOND, true);
+testIsFileNewer("two second later is newer" , m_testFile1, 
fileLastModified - TWO_SECOND, true);
 }
 
 /**
@@ -86,7 +86,7 @@
 if (imaginaryFile.exists())
 throw new IllegalStateException("The imaginary File exists");
 
-testIsFileNewer("imaginary file can be newer" , imaginaryFile, 0, 
false);
+testIsFileNewer("imaginary file can be newer" , imaginaryFile, 
m_testFile2.lastModified(), false);
 }
 
 /**
@@ -118,8 +118,7 @@
 File temporaryFile = m_testFile2;
 
 temporaryFile.setLastModified(time);
-if (temporaryFile.lastModified() != time)
-throw new IllegalStateException("The temporary file hasn't the 
right last modification date");
+assertEquals("The temporary file hasn't the right last modification 
date", time, temporaryFile.lastModified());
 assertEquals(description + " - file", wantedResult, 
FileUtils.isFileNewer(file, temporaryFile));
 }
 

Modified: 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java?rev=369049&r1=369048&r2=369049&view=diff
==
--- 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
 (original)
+++ 
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
 Sat Jan 14 08:55:58 2006
@@ -461,7 +461,7 @@
 public void testAgeFilter() throws Exception {
 File oldFile = new File(getTestDirectory(), "old.txt");
 createFile(oldFile, 0);
-spin();
+spin(oldFile.lastModified());
 long now = System.currentTimeMillis();
 IOFileFilter filter1 = FileFilterUtils.ageFileFilter(now);
 IOFileFilter filter2 = FileFilterUtils.ageFileFilter(now, true);
@@ -475,7 +475,7 @@
 IOFileFilter filter7 = FileFilterUtils.ageFileFilter(reference);
 IOFileFilter filter8 = FileFilterUtils.ageFileFilter(reference, true);
 IOFileFilter filter9 = FileFilterUtils.ageFileFilter(reference, false);
-spin();
+spin(reference.lastModified());
 File newFile = new File(getTestDirectory(), "new.txt");
 createFile(newFile, 0);
 
@@ -523,8 +523,7 @@
 }
 }
 
-private void spin() {
-long now = System.currentTimeMillis();
+private void spin(long now) {
 while (System.currentTimeMillis() <= now);
 }
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-commons Wiki] Update of "SCXML" by TimObrien

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" 
for change notification.

The following page has been changed by TimObrien:
http://wiki.apache.org/jakarta-commons/SCXML

The comment on the change is:
Added a link to a SCXML FAQ - should dev in the Wiki and mv core ques to site

--
  
   * ''Will Commons SCXML engine be able to execute this state machine?'' - 
You'll have to try that, but as a project we sure hope to.
  
+  * ''I've got a question, can you answer it?'' - Take a look at the 
[wiki:/SCXMLFaq FAQs].
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [id] Review before 1.0 (Summary)

[Stephen Colebourne]

Tim OBrien wrote:

--- Jörg Schaible <[EMAIL PROTECTED]> wrote:

4/ Copied c-codec classes in official API

To remove a dependency to c-codec the digest and hex utilities have been
copied to c-id, but they are now publicly available in the o.a.c.id
namespace.

Martin already proposed to move them to a package o.a.c.id.internal and
provide an appropriate package.html. As alternative we could try to make
them package accessible only and remove any unused functionality (they have
bad coverage reports because we only use view methods).



+1 with moving into an internal package with a package.html,  


I strongly prefer using package scope if at all possible, and 
referencing the svn revision id that the code was copied from.


Stephen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38274] - [scxml] Add another use case that isn't Voice (RDC) or MVC (Shale)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38274





--- Additional Comments From [EMAIL PROTECTED]  2006-01-14 17:43 ---
I had to use a stopwatch state machine (ready/running/paused/stopped) to
actually understand SCXML for Javapolis. This may be a simple four state machine
that could be used here.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [id] Review before 1.0 (Summary)

[Tim OBrien]

--- Jörg Schaible <[EMAIL PROTECTED]> wrote:

> Hi Tim,
> 
> Tim OBrien wrote:
> 
> > Good summary, comments inline...
> > 
> > --- Jörg Schaible <[EMAIL PROTECTED]> wrote:
> > 
> >> 4/ Copied c-codec classes in official API
> >> 
> >> To remove a dependency to c-codec the digest and hex utilities have been
> >> copied to c-id, but they are now publicly available in the o.a.c.id
> >> namespace.
> >> 
> >> Martin already proposed to move them to a package o.a.c.id.internal and
> >> provide an appropriate package.html. As alternative we could try to make
> >> them package accessible only and remove any unused functionality (they
> >> have bad coverage reports because we only use view methods).
> > 
> > +1 with moving into an internal package with a package.html,
> > 
> > Of two minds on the coverage issue, one one hand the class is well tested
> > over in codec so you
> > could just trust that the class is well tested.  But, could you also just
> > copy the unit tests from
> > c-codec and add them into c-id.  I don't see a huge problem there as long
> > as there is sufficient notice in the classes to the effect of "DON'T
> > CHANGE ME HERE, CHANGE ME IN COMMONS CODEC".
> 
> If you remove the unused code, you have no tests, but coverage :)
> 

Definitely, I see the point, I was just concerned that you might be removing 
something that might
eventually be needed, but if you are covering c-id code you know exactly what 
is needed and what
isn't.  

> Also it is much less encouraging for people to use these classes, if you
> state that you have only a partial copy of the original ...
> 

Definitely.

> - Jörg
> 
> 
> 
> -
> 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]

DO NOT REPLY [Bug 38276] New: - [scxml] More Explicit Instructions on core-engine.html

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38276

   Summary: [scxml] More Explicit Instructions on core-engine.html
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Sandbox
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Similar issue on core-engine.html as core-digester.html.  While we show the
end-user a clear path towards getting the Executor to work, we use placeholders
for the Evaluator, EventDispatcher, and ErrorReporter.  

The document needs sections on all three objects, how to create them, what they
do.  The document could also use a more general discussion of the components
that are involved in the execution.  

"An engine, once initialized, should be cached till the state machine reaches a
terminal or "final" state, and no more." - That sentence especially needs a
little more definition.  

Page needs to explain all of the methods on the Executor, for example, while the
code uses SuperStep, it doesn't explain what that particular call accomplishes.
  Also, the documentation should be clear about when the Executor starts to
dispatch events.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [id] Review before 1.0 (Summary)

[Jörg Schaible]

Hi Tim,

Tim OBrien wrote:

> Good summary, comments inline...
> 
> --- Jörg Schaible <[EMAIL PROTECTED]> wrote:
> 
>> 4/ Copied c-codec classes in official API
>> 
>> To remove a dependency to c-codec the digest and hex utilities have been
>> copied to c-id, but they are now publicly available in the o.a.c.id
>> namespace.
>> 
>> Martin already proposed to move them to a package o.a.c.id.internal and
>> provide an appropriate package.html. As alternative we could try to make
>> them package accessible only and remove any unused functionality (they
>> have bad coverage reports because we only use view methods).
> 
> +1 with moving into an internal package with a package.html,
> 
> Of two minds on the coverage issue, one one hand the class is well tested
> over in codec so you
> could just trust that the class is well tested.  But, could you also just
> copy the unit tests from
> c-codec and add them into c-id.  I don't see a huge problem there as long
> as there is sufficient notice in the classes to the effect of "DON'T
> CHANGE ME HERE, CHANGE ME IN COMMONS CODEC".

If you remove the unused code, you have no tests, but coverage :)

Also it is much less encouraging for people to use these classes, if you
state that you have only a partial copy of the original ...

- Jörg



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38275] New: - [scxml] More Explicit Instructions on core-digester.html

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38275

   Summary: [scxml] More Explicit Instructions on core-digester.html
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Sandbox
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The page that contains notes about running the SCXMLDigester contains:

scxml = SCXMLDigester.digest(, ,
, );

This page could use a few more details.  Specifically the following dedicated
sections need to be added:

1. Creating a Context for SCXMLDigester
2. Creating an Evaluator for SCXMLDigester

Additionally, the code sample should be more detailed showing all the necessary
code one needs to write to read in an SCXML document.  We can safely assume that
end-users know how to get a URL and ErrorHandler object, but this is the page
that people are going to go to for a step-by-step guide/reference about
consuming SCXML documents with c-scxml.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [id] Review before 1.0 (Summary)

[Tim OBrien]

Good summary, comments inline...

--- Jörg Schaible <[EMAIL PROTECTED]> wrote:

> 4/ Copied c-codec classes in official API
> 
> To remove a dependency to c-codec the digest and hex utilities have been
> copied to c-id, but they are now publicly available in the o.a.c.id
> namespace.
> 
> Martin already proposed to move them to a package o.a.c.id.internal and
> provide an appropriate package.html. As alternative we could try to make
> them package accessible only and remove any unused functionality (they have
> bad coverage reports because we only use view methods).

+1 with moving into an internal package with a package.html,  

Of two minds on the coverage issue, one one hand the class is well tested over 
in codec so you
could just trust that the class is well tested.  But, could you also just copy 
the unit tests from
c-codec and add them into c-id.  I don't see a huge problem there as long as 
there is sufficient
notice in the classes to the effect of "DON'T CHANGE ME HERE, CHANGE ME IN 
COMMONS CODEC".



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38274] New: - [scxml] Add another use case that isn't Voice (RDC) or MVC (Shale)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38274

   Summary: [scxml] Add another use case that isn't Voice (RDC) or
MVC (Shale)
   Product: Commons
   Version: unspecified
  Platform: Other
   URL: http://jakarta.apache.org/commons/sandbox/scxml/usecases
.html
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Sandbox
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


SCXML has two good use case documents, one is about RDC and one about Shale
dialogs.  There are a good start, but it would be helpful if SCXML had another
usecase that wasn't tied to either a voice application or a web MVC framework. 
Something at a conceptual level that people looking to use SCXML for a general
finite state machine can relate to without having to be familiar with another
framework.

The question is, what should this example be?  We could use the Microwave
example from the working draft, but that might be too much for a quick
introduction.  Instead it might be better to choose something that doesn't have
parallel states, maybe the status of a document in a content management system
with four/five simple states and simple transitions that just shows off the
basic usecases of the state machine execution environment in a standalone
environment.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r369036 - /jakarta/commons/sandbox/id/trunk/project.xml

[joehni]

Author: joehni
Date: Sat Jan 14 07:37:02 2006
New Revision: 369036

URL: http://svn.apache.org/viewcvs?rev=369036&view=rev
Log:
Fix package declaration.

Modified:
jakarta/commons/sandbox/id/trunk/project.xml

Modified: jakarta/commons/sandbox/id/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/project.xml?rev=369036&r1=369035&r2=369036&view=diff
==
--- jakarta/commons/sandbox/id/trunk/project.xml (original)
+++ jakarta/commons/sandbox/id/trunk/project.xml Sat Jan 14 07:37:02 2006
@@ -32,7 +32,7 @@
 http://jakarta.apache.org
 http://jakarta.apache.org/images/original-jakarta-logo.gif
   
-  org.apache.commons.id.*
+  org.apache.commons.id
   http://jakarta.apache.org/commons/sandbox/id
   0.1-dev
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[scxml] compliance with SCXML Working Draft

[Tim OBrien]

I'm trying to use SCXMLDigester to read an SCXML file without an "initialstate" 
attribute defined
on the  document element.  Doing so throws a "SEVERE: No SCXML child 
state with ID "null"
found; illegal initialstate for SCXML document"

The Working Draft (http://www.w3.org/TR/2005/WD-scxml-20050705/#Semantics) 
doesn't specify whether
or not the initialstate attribute is required, and from the examples in 
sections E1 and E2, SCXML
documents without this attribute are presented.  I'm assuming that there can be 
state chart XML
documents that do not specify an initial state until the draft is updated.

updateSCXML in SCXMLDigester assumes that this attribute is present.  Rahil, I 
propose that if the
initialstate is not present this method shouldn't print an error message 
"SEVERE", it should just
skip setting the initialstate.  I believe that the default behavior works, but 
the error message
is misleading.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: clirr

[Stephen Colebourne]

I think I had to use ant to run it last as the maven plugin didn't work 
for me. YMMV


Stephen


Torsten Curdt wrote:

Guys,

anyone using clirr through maven? I would like to have
it done (be)for(e) the BCEL release. But it would probably
also make sense for the commons projects.

cheers
--
Torsten


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[id] Review before 1.0 (Summary)

[Jörg Schaible]

Hi folks,

reviewing c-id I found more issues to resolve before releasing 1.0 final.
Since I already reported different complaints, I create here a summary of
anything already reported and all new issues.

1/ Concept of IdentifierGeneratorFactory

The IdentifierGeneratorFactory provides a easy-to-use concept for casual use
of id generators. Three elements are part of it:

abstract class IdentifierGeneratorFactory - defines the generator types
class DefaultIdentifierGeneratorFactory - delivers implementations
class IdentifierUtils - easy id generation using the default factory

the basic idea is, that a user can implement an own factory and provide it
with a system factory and it is automatically used as default in the
IdentifierUtils - so far so good.

The bad part in the concept is, that we have a variety of generator
implementations and all of them are quite different in their
initialization. Therefore has the IdentifierGeneratorFactory not only three
simple methods to generate the default generator for each (currently
supported) id type (String, Long and UUID), but has a variety of methods
tailored exactly for the ctors of the different generator implementations,
which makes this "factory" quite obscure.

Modifying a class with every new implementations is for me a kind of "code
smell". And the current code already gives evidence of this, since we have
new generator implementations, that cannot be accessed/initialized with the
factory. Additionally some methods have been added to support newer
generator implementations, but the appropriate methods to make use of the
generated ids are missing in the IdentifierUtils.

So we either complete those 3 classes for all generator implementations or
tailor them to a useful subset for the casual user: 

interface IdentifierGeneratorFactory {
LongIdentifierGenerator longIDentifierGenerator();
StringIdentifierGenerator stringIDentifierGenerator();
UUIDIdentifierGenerator uuidIDentifierGenerator();
}

The question is, if a user *normally* requires in one application different
UUID genenerators, string generators or long generators?  In all special
cases the generator instance can be generated directly or by an appropriate
environment (standard use case in IoC containers, where the implementation
and their initialization is configured anyway).

Proposal: Use as default a VersionFourGenerator, SessionIdGenerator and
LongGenerator. If he has the need for a different generator or a different
initialization, he can still provide easily an own factory and set the
system property.

2/ Exception handling for UUID 1 generator state

Currently c-id cannot be compiled with JDK 1.3, since it uses the ctor of
the RuntimeException with a causing Throwable. While this can easily
removed, the concepts leading to the situation must be reconsidered.

The UUID1 generation supports several implementations to persist the state
of such an generator. The State interface has a load and store method that
throw both just an arbitrary Exception, mainly because the underlying
implementation may have any kind of problems reading or storing the state
(XML parser, IO, DB, ...). The funny part is, that such an exception is
wrapped by the RuntimeEx from above and from the user's PoV he might get a
bad surprise calling nextIdentifier() on a UUID 1 generator ...

Proposal: Introduce a StatePerstistenceException derived from RTEx, that
might be thrown from the State implementations and document this at the
proper places in javadoc.

3/ xxxStateImpl classes

The javadoc of ReadOnlyResourceStateImpl implies that the implementation
tries to discover (well, use c-discovery) to load a file "uuid-[n].conf".
In reality it expects a system property (wrong name documented) set to a
file name that can be loaded as resource. All unit tests use a file
"uuid1.state", that is only available during the tests.

I am just wondering, if a default is simply missing or left by intension.

Also the derived ReadWriteFileStateImpl tries to write into the URL of the
resource ... which will fail badly if the file is within a jar.

4/ Copied c-codec classes in official API

To remove a dependency to c-codec the digest and hex utilities have been
copied to c-id, but they are now publicly available in the o.a.c.id
namespace.

Martin already proposed to move them to a package o.a.c.id.internal and
provide an appropriate package.html. As alternative we could try to make
them package accessible only and remove any unused functionality (they have
bad coverage reports because we only use view methods).

5/ Unit tests

A lot of unit tests in the c-id package have own suite methods and set an
own name for the test. While there are situations, where the usage of a
suite can be necessary, here it is definitely not. This not only results in
an inconsistent unit test report, but also prevents, that e.g. in Eclipse I
can simply double click the test to get to the appropriate code.

Proposal: Remove unnecessary suite m

Re: [vote] access for Niklas Gustavsson to the sandbox

[robert burrell donkin]

+1

- robert

On Fri, 2006-01-13 at 10:18 +1100, Brett Porter wrote:
> Hi,
> 
> I know the sandbox is meant to be open to any committers on request, but
> Niklas is a recent addition to an incubator project, so I thought it is
> best to double check with a vote.
> 
> Niklas contributed the original Ant refactoring to start commons-exec,
> and has some outstanding patches that I haven't had time to review and
> apply yet. I suspect I'm getting in his way right now.
> 
> I'd like to grant him access to commit to the sandbox so he can improve
> and document exec. I think at this point this is essential to give it
> some momentum. Plenty of people are interested, but they need to be able
> to use it first :)
> 
> I can still do lazy review and discuss the design on the list.
> 
> +1 from me.
> 
> - Brett
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


signature.asc
Description: This is a digitally signed message part

Re: clirr

[robert burrell donkin]

On Sat, 2006-01-14 at 19:47 +1100, Torsten Curdt wrote:
> Guys,
> 
> anyone using clirr through maven? I would like to have
> it done (be)for(e) the BCEL release. But it would probably
> also make sense for the commons projects.

i've used it with maven 1. i've had an itch about creating a problem
clirr report one day (when i find time) but have never got round to it.

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-jelly-tags-define-test (in module commons-jelly) failed

[commons-jelly-tags-define development]

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-jelly-tags-define-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-define-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html
Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
[junit] at 
org.jaxen.saxpath.base.XPathReader.unionExpr(XPathReader.java:1129)
[junit] at 
org.jaxen.saxpath.base.XPathReader.unaryExpr(XPathReader.java:1117)
[junit] at 
org.jaxen.saxpath.base.XPathReader.multiplicativeExpr(XPathReader.java:1039)
[junit] at 
org.jaxen.saxpath.base.XPathReader.additiveExpr(XPathReader.java:982)
[junit] at 
org.jaxen.saxpath.base.XPathReader.relationalExpr(XPathReader.java:902)
[junit] at 
org.jaxen.saxpath.base.XPathReader.equalityExpr(XPathReader.java:850)
[junit] at 
org.jaxen.saxpath.base.XPathReader.andExpr(XPathReader.java:826)
[junit] at 
org.jaxen.saxpath.base.XPathReader.orExpr(XPathReader.java:804)
[junit] at org.jaxen.saxpath.base.XPathReader.expr(XPathReader.java:797)
[junit] at 
org.jaxen.saxpath.base.XPathReader.parse(XPathReader.java:105)
[junit] at org.jaxen.BaseXPath.(BaseXPath.java:126)
[junit] at org.jaxen.BaseXPath.(BaseXPath.java:152)
[junit] at org.jaxen.dom4j.Dom4jXPath.(Dom4jXPath.java:101)
[junit] at 
org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78)
[junit] at 
org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] at junit.framework.TestCase.runBare(TestCase.java:127)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework

[EMAIL PROTECTED]: Project commons-jelly-tags-define-test (in module commons-jelly) failed

[commons-jelly-tags-define development]

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-jelly-tags-define-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-define-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html
Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
[junit] at 
org.jaxen.saxpath.base.XPathReader.unionExpr(XPathReader.java:1129)
[junit] at 
org.jaxen.saxpath.base.XPathReader.unaryExpr(XPathReader.java:1117)
[junit] at 
org.jaxen.saxpath.base.XPathReader.multiplicativeExpr(XPathReader.java:1039)
[junit] at 
org.jaxen.saxpath.base.XPathReader.additiveExpr(XPathReader.java:982)
[junit] at 
org.jaxen.saxpath.base.XPathReader.relationalExpr(XPathReader.java:902)
[junit] at 
org.jaxen.saxpath.base.XPathReader.equalityExpr(XPathReader.java:850)
[junit] at 
org.jaxen.saxpath.base.XPathReader.andExpr(XPathReader.java:826)
[junit] at 
org.jaxen.saxpath.base.XPathReader.orExpr(XPathReader.java:804)
[junit] at org.jaxen.saxpath.base.XPathReader.expr(XPathReader.java:797)
[junit] at 
org.jaxen.saxpath.base.XPathReader.parse(XPathReader.java:105)
[junit] at org.jaxen.BaseXPath.(BaseXPath.java:126)
[junit] at org.jaxen.BaseXPath.(BaseXPath.java:152)
[junit] at org.jaxen.dom4j.Dom4jXPath.(Dom4jXPath.java:101)
[junit] at 
org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78)
[junit] at 
org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] at junit.framework.TestCase.runBare(TestCase.java:127)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework

[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed

[commons-jelly-tags-jsl development]

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-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jsl-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property 
maven.jar.ant-optional.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html
Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
[junit] at 
org.apache.commons.jelly.tags.xml.ExprTag.doTag(ExprTag.java:46)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234)
[junit] at 
org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58)
[junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:79)
[junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91)
[junit] at org.d

[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed

[commons-jelly-tags-jsl development]

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-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jsl-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property 
maven.jar.ant-optional.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html
Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
[junit] at 
org.apache.commons.jelly.tags.xml.ExprTag.doTag(ExprTag.java:46)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234)
[junit] at 
org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58)
[junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:79)
[junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:58)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102)
[junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91)
[junit] at org.d

[EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) failed

[commons-jelly-tags-html development]

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-jelly-tags-html has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-html :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-html-14012006.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: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html
Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
  You must define an attribute called 'test' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
  You must define an attribute called 'test' for this tag.
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48:
  You must define an attribute called 'test' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48:
  You must define an attribute called 'test' for this tag.
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54)

[EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) failed

[commons-jelly-tags-html development]

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-jelly-tags-html has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-html :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-html-14012006.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: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html
Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
  You must define an attribute called 'test' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48:
  You must define an attribute called 'test' for this tag.
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48:
  You must define an attribute called 'test' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48:
  You must define an attribute called 'test' for this tag.
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54)

[EMAIL PROTECTED]: Project commons-jelly-tags-swing (in module commons-jelly) failed

[JellySwing development]

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-jelly-tags-swing has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-swing :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-swing-14012006.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: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports
 -WARNING- No directory 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/gump_work/build_commons-jelly_commons-jelly-tags-swing.html
Work Name: build_commons-jelly_commons-jelly-tags-swing (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/commons-jelly-tags-define-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/interaction/target/commons-jelly-tags-interaction-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:308)
at java.lang.Class.newInstance(Class.java:261)
at 
org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:432)
at 
org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.java:171)
at 
org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1033)
at 
org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java:647)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
Source)
at 
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
at 
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown 

[EMAIL PROTECTED]: Project commons-jelly-tags-swing (in module commons-jelly) failed

[JellySwing development]

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-jelly-tags-swing has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-swing :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-swing-14012006.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: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports
 -WARNING- No directory 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing/target/test-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-swing/gump_work/build_commons-jelly_commons-jelly-tags-swing.html
Work Name: build_commons-jelly_commons-jelly-tags-swing (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/swing]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/commons-jelly-tags-define-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/interaction/target/commons-jelly-tags-interaction-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:308)
at java.lang.Class.newInstance(Class.java:261)
at 
org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:432)
at 
org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.java:171)
at 
org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:1033)
at 
org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java:647)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
Source)
at 
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
at 
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown 

[EMAIL PROTECTED]: Project commons-jelly-tags-xml-test (in module commons-jelly) failed

[commons-jelly-tags-xml development]

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-jelly-tags-xml-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-xml-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/gump_work/build_commons-jelly_commons-jelly-tags-xml-test.html
Work Name: build_commons-jelly_commons-jelly-tags-xml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 41 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testSetSingleNodeAndAsString(org.apache.commons.jelly.tags.junit.CaseTag$1):
  Caused an ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81:
  You must define an attribute called 'select' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81:
  You must define an attribute called 'select' for this tag.
[junit] at 
org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testSetStringLists(org.apache.commons.jelly.tags.junit.CaseTag$1):
Caused an ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82:
  You must define an attribute called 'select' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82:
  You must define an attribute called 'select' for this tag.
[junit] at 
org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testEntities(org.apache.commons.jelly.tags.junit.CaseTag$1):  Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/comm

[EMAIL PROTECTED]: Project commons-jelly-tags-xml-test (in module commons-jelly) failed

[commons-jelly-tags-xml development]

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-jelly-tags-xml-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-xml-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml-test/gump_work/build_commons-jelly_commons-jelly-tags-xml-test.html
Work Name: build_commons-jelly_commons-jelly-tags-xml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 41 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-14012006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testSetSingleNodeAndAsString(org.apache.commons.jelly.tags.junit.CaseTag$1):
  Caused an ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81:
  You must define an attribute called 'select' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:294:81:
  You must define an attribute called 'select' for this tag.
[junit] at 
org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testSetStringLists(org.apache.commons.jelly.tags.junit.CaseTag$1):
Caused an ERROR
[junit] 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82:
  You must define an attribute called 'select' for this tag.
[junit] org.apache.commons.jelly.MissingAttributeException: 
file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:339:82:
  You must define an attribute called 'select' for this tag.
[junit] at 
org.apache.commons.jelly.tags.xml.SetTag.doTag(SetTag.java:86)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] 
[junit] 
[junit] Testcase: 
testEntities(org.apache.commons.jelly.tags.junit.CaseTag$1):  Caused an 
ERROR
[junit] 
file:/x1/gump/public/workspace/comm

[EMAIL PROTECTED]: Project commons-jelly-test (in module commons-jelly) failed

[commons-jelly development]

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-jelly-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for 
property maven.jar.servletapi.
 -DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for 
property maven.jar.jstl.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/gump_work/build_commons-jelly_commons-jelly-test.html
Work Name: build_commons-jelly_commons-jelly-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 55 secs
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/forehead/forehead-1.0-beta-5.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
 At tag : line: 359 column: 75
[junit] org.apache.commons.jelly.JellyTagException: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly:359:75:
   expected:[22] but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
 At tag : line: 359 column: 75
[junit] at 
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:712)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] Caused by: 
org.apache.commons.jelly.tags.junit.JellyAssertionFailedError:  expected:[22] 
but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
 At tag : line: 359 column: 75
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:39)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.failNotEquals(AssertTagSupport.java:62)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertEqualsTag.doTag(AssertEqualsTag.java:55)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
  

[EMAIL PROTECTED]: Project commons-jelly-test (in module commons-jelly) failed

[commons-jelly development]

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-jelly-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for 
property maven.jar.servletapi.
 -DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for 
property maven.jar.jstl.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/gump_work/build_commons-jelly_commons-jelly-test.html
Work Name: build_commons-jelly_commons-jelly-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 55 secs
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/forehead/forehead-1.0-beta-5.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
 At tag : line: 359 column: 75
[junit] org.apache.commons.jelly.JellyTagException: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly:359:75:
   expected:[22] but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
 At tag : line: 359 column: 75
[junit] at 
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:712)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
[junit] at 
org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59)
[junit] Caused by: 
org.apache.commons.jelly.tags.junit.JellyAssertionFailedError:  expected:[22] 
but was:[22]
[junit] Expected expression: ${singleSize*2}
[junit] Actual expression: ${doubleSize} File: 
file:/x1/gump/public/workspace/commons-jelly/target/test-classes/org/apache/commons/jelly/suite.jelly
 At tag : line: 359 column: 75
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:39)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.failNotEquals(AssertTagSupport.java:62)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertEqualsTag.doTag(AssertEqualsTag.java:55)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
  

[EMAIL PROTECTED]: Project commons-id (in module jakarta-commons-sandbox) failed

[Adam Jack]

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-id 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-id :  Commons Identifier Package


Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-id-14012006.jar] identifier set to project name
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html
Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 secs
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

The build cannot continue because of the following unsatisfied dependency:

maven-cobertura-plugin-1.1.1.jar (try downloading from 
http://maven-plugins.sourceforge.net/maven-cobertura-plugin/)

Total time: 2 seconds
Finished at: Sat Jan 14 02:43:58 PST 2006

-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2014012006, vmgump.apache.org:vmgump-public:2014012006
Gump E-mail Identifier (unique within run) #15.

--
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-id (in module jakarta-commons-sandbox) failed

[Adam Jack]

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-id 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-id :  Commons Identifier Package


Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-id-14012006.jar] identifier set to project name
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html
Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 secs
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-14012006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-14012006.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

The build cannot continue because of the following unsatisfied dependency:

maven-cobertura-plugin-1.1.1.jar (try downloading from 
http://maven-plugins.sourceforge.net/maven-cobertura-plugin/)

Total time: 2 seconds
Finished at: Sat Jan 14 02:43:58 PST 2006

-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2014012006, vmgump.apache.org:vmgump-public:2014012006
Gump E-mail Identifier (unique within run) #15.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36892] - Create a "secure" package

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36892





--- Additional Comments From [EMAIL PROTECTED]  2006-01-14 11:04 ---
Ralf, do you see this belonging to one of the current commons component or is it
a brand new component?

This issue is currently attached to the site which just handles the site, no
code base. I would like to move this issue. If you can't think of a current
component for this I'd like to move it to the sandbox component, if that's OK
with you.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

clirr

[Torsten Curdt]

Guys,

anyone using clirr through maven? I would like to have
it done (be)for(e) the BCEL release. But it would probably
also make sense for the commons projects.

cheers
--
Torsten


PGP.sig
Description: This is a digitally signed message part