[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 90 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-scxml-test : Apache Commons
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-WARNING- Overriding Maven settings:
[/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml]
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml
-INFO- Project Reports in:
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 27 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -Dsimplelog.defaultlog=info
--settings
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1
[INFO] SimpleSCXMLListener - /s2
[INFO] SimpleSCXMLListener - transition (event = s2.1.done, cond = null, from =
/s2, to = /s3)
[INFO] SimpleSCXMLListener - /s3
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.311 sec
Running org.apache.commons.scxml.issues.Issue64Test
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: somedata
[INFO] SCXMLSemantics - null: *somedata
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from =
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
[WARN] SCXMLParser - Ignoring element in namespace
"http://www.w3.org/2005/07/scxml"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:30:21
and digester match "scxml/datamodel/misplaced"
[WARN] SCXMLParser - Ignoring element in namespace
"http://www.w3.org/2005/07/scxml"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:36:19
and digester match "scxml/state/onentry/foo"
[WARN] SCXMLParser - Ignoring element in namespace
"http://my.foo.example/"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:37:22
and digester match "scxml/state/onentry/bar"
[WARN] SCXMLParser - Ignoring element in namespace
"http://www.w3.org/2005/07/scxml"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:41:21
and digester match "scxml/state/transition/datamodel"
[WARN] SCXMLParser - Ignoring element in namespace
"http://www.w3.org/2005/07/scxml"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:42:41
and digester match "scxml/state/transition/datamodel/data"
[WARN] SCXMLParser - Ignoring element in namespace
"http://my.foo.example/"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:49:14
and digester match "scxml/baz"
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: null
[WARN] SimpleErrorReporter - EXPRESSION_ERROR (eval(''*' + dummy'):null):
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from =
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.101 sec
Results :
Failed tests:
testCustomActionCallbacks(org.apache.commons.scxml.model.CustomActionTest)
Tests run: 229, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO]
[GUMP@vmgump]: Project commons-jelly-tags-sql (in module commons-jelly) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-jelly-tags-sql has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 18 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-sql : Commons Jelly
Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-jelly-tags-sql-20092012.jar] identifier set
to project name
-DEBUG- Dependency on xml-xerces exists, no need to add for property
maven.jar.xerces.
-DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property
maven.jar.commons-jexl.
-DEBUG- (Apache Gump generated) Apache Maven Properties in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/project.xml
-DEBUG- Maven project properties in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/project.properties
-INFO- Project Reports in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/test-reports
-WARNING- No directory
[/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/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-sql/gump_work/build_commons-jelly_commons-jelly-tags-sql.html
Work Name: build_commons-jelly_commons-jelly-tags-sql (Type: Build)
Work ended in a state of : Failed
Elapsed: 6 secs
Command Line: maven --offline jar
[Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/sql]
-
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
You are working offline so the build will continue, but
commons-jelly-1.1-SNAPSHOT.jar may be out of date!
build:start:
java:prepare-filesystem:
[mkdir] Created dir:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
java:compile:
[echo] Compiling to
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
[javac] Compiling 18 source files to
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
[javac] warning: [options] bootstrap class path not set in conjunction with
-source 1.5
[javac]
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/src/java/org/apache/commons/jelly/tags/sql/DataSourceWrapper.java:38:
error: DataSourceWrapper is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[javac] public class DataSourceWrapper implements DataSource {
[javac]^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error
[javac] 1 warning
BUILD FAILED
File.. /home/gump/.maven/cache/maven-java-plugin-1.5/plugin.jelly
Element... ant:javac
Line.. 63
Column 48
Compile failed; see the compiler error output for details.
Total time: 6 seconds
Finished at: Thu Sep 20 07:31:46 UTC 2012
-
To subscribe to this information via syndicated feeds:
- RSS:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/rss.xml
- Atom:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/atom.xml
== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 1220092012, vmgump.apache.org:vmgump:1220092012
Gump E-mail Identifier (unique within run) #61.
--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] HDFS provider
Hi Dave! Welcome to commons! :) What you are proposing makes a lot of sense IMHO! Unfortunately I am not so familiar with VFS to review & apply your modifications, guess it would be easier to do if you could provide a patch via JIRA. Good luck and all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Sep 20, 2012 at 4:04 AM, wrote: > > I did not see a provider for HDFS on the list of supported file systems. I > created a read-only HDFS provider while working on an Accumulo ticket. I was > wondering if one of the devs had time to review to see if I made any glaring > mistakes. I am in the process of becoming an Accumulo committer, so I'm > assuming that this file system provider could be included in the VFS project > if it makes sense. Thanks, > > Dave Marion - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [math] Adding some methods in Precision class (oacm.util)
> De : Tanguy Yannick [mailto:yannick.tan...@cnes.fr]
> About the default value (1e-14), I know the tolerance is case-
> dependant, but some times, we don't precisely know the order of
> magnitude (ex : jacobians matrices) and it's quite practical to have a
> default value.
Hi,
A point of the discussion with Gilles in the MATH-863 (new Quaternion class) is
about this magic 1E-14. ;)
Consider the following methods:
public Quaternion normalize() {
final double norm = getNorm();
if (norm >= Precision.SAFE_MIN) {
return new Quaternion(q0 / norm, q1 / norm, q2 / norm, q3 / norm);
} else {
throw new ZeroException();
}
}
public boolean isUnitQuaternion() {
final double norm = getNorm();
if (Precision.equals(norm, 1.0, Precision.EPSILON)) {
return true;
} else {
return false;
}
}
=> There are many cases where
myQuaternion.normalize().isUnitQuaternion()
returns "false".
The Precision.EPSILON is too small. That's why we use this "historical"
arbitrary tolerance of 1E-14.
Do you think that adding a tolerance parameter in this method
isUnitQuaternion() (and in its neighboors) is a good idea ?
Julien
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Adding some methods in Precision class (oacm.util)
Hi,
2012/9/20 Anxionnat Julien :
>> De : Tanguy Yannick [mailto:yannick.tan...@cnes.fr]
>> About the default value (1e-14), I know the tolerance is case-
>> dependant, but some times, we don't precisely know the order of
>> magnitude (ex : jacobians matrices) and it's quite practical to have a
>> default value.
>
> Hi,
> A point of the discussion with Gilles in the MATH-863 (new Quaternion class)
> is about this magic 1E-14. ;)
>
> Consider the following methods:
>
> public Quaternion normalize() {
> final double norm = getNorm();
> if (norm >= Precision.SAFE_MIN) {
> return new Quaternion(q0 / norm, q1 / norm, q2 / norm, q3 / norm);
> } else {
> throw new ZeroException();
> }
> }
>
> public boolean isUnitQuaternion() {
> final double norm = getNorm();
> if (Precision.equals(norm, 1.0, Precision.EPSILON)) {
> return true;
> } else {
> return false;
> }
> }
>
>
> => There are many cases where
>
> myQuaternion.normalize().isUnitQuaternion()
> returns "false".
>
> The Precision.EPSILON is too small. That's why we use this "historical"
> arbitrary tolerance of 1E-14.
>
>
> Do you think that adding a tolerance parameter in this method
> isUnitQuaternion() (and in its neighboors) is a good idea ?
>
>
> Julien
>
I think a tolerance parameter which defaults to 1E-14 in my view be
the best option. I have nothing against this magic number; I just
don't think that it should sit in the general class Precision. I think
this is also what makes Gilles unhappy (TBC). How about a static final
double Quaternion.DEFAULT_TOL, instead of Precision.DEFAULT_TOL?
Sébastien
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] APT format for the users guide
Hi.
> as I previously said, I'd like to extend the user's guide for the
> special functions package. I am not a big fan of the xdoc format
> currently in use, at is not easily readable. So I thought I would give
> APT a go. Please find below the code corresponding to the current
> "Special Functions" page.
Can it be used to write math symbols/formulae?
> The learning curve is not steep at all (about 5 minutes!). I think
> it's much better (even for tables, which might require a large screen
> ;)).
What's the advantage over the Wiki syntax?
>
> The generated pages are identical (I've even reproduced the typo in
> 5.4...), but for the fact that you cannot have anchors with a name
> different from the text they refer to. So anchor {Beta} would be named
> "Beta", and not "beta" as is currently the case. I don't think this is
> much of an issue, as there is no reference to these anchors (I'll
> check the other pages of the user's guide, and update them if
> necessary).
>
> So, what do you think? Should I pursue, or would you like me to stay
> with the xdoc format?
My opinion is that we should figure out the kind of contents the document
will contain, and choose the (possibly different) language(s) accordingly.
> I would like to emphasize I'm not advocating for a complete switch
> from one format to another. But since I'm going to concentrate on this
> section of the users guide, I thought I might as well choose the
> format which I am most comfortable with. If you do not like the idea
> of having two different formats for the same site, please let me know.
If we can agree to keep the user guide simple (i.e. limited to "To do
, you call with , then retrieve the result as
follows..." etc., with some verbatim code examples), then there is an
advantage to having a source syntax that looks like plain text:
* simple to write,
* easy to read.
But if we want to show the math that corresponds to the code, then we loose
everything:
* difficult to write (either including preprocessed figures or ad-hoc
syntax)
* impossible to read (in the source).
Loosely related to this discussion: What would you think of splitting the
user guide into several independent tutorials? That would be more in the
spirit of simple "howto"s (as opposed to a sort of "reference" which should
allow for more formatting power, a la LaTeX).
[And that would make it less strange to have different source formats.]
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
RE: [math] Adding some methods in Precision class (oacm.util)
>Hi,
>2012/9/20 Anxionnat Julien :
>>> De : Tanguy Yannick [mailto:yannick.tan...@cnes.fr] About the default
>>> value (1e-14), I know the tolerance is case- dependant, but some
>>> times, we don't precisely know the order of magnitude (ex : jacobians
>>> matrices) and it's quite practical to have a default value.
>>
>> Hi,
>> A point of the discussion with Gilles in the MATH-863 (new Quaternion
>> class) is about this magic 1E-14. ;)
>>
>> Consider the following methods:
>>
>> public Quaternion normalize() {
>> final double norm = getNorm();
>> if (norm >= Precision.SAFE_MIN) {
>> return new Quaternion(q0 / norm, q1 / norm, q2 / norm, q3 /
>> norm);
>> } else {
>> throw new ZeroException();
>> }
>> }
>>
>> public boolean isUnitQuaternion() {
>> final double norm = getNorm();
>> if (Precision.equals(norm, 1.0, Precision.EPSILON)) {
>> return true;
>> } else {
>> return false;
>> }
>> }
>>
>>
>> => There are many cases where
>>
>> myQuaternion.normalize().isUnitQuaternion()
>> returns "false".
>>
>> The Precision.EPSILON is too small. That's why we use this "historical"
>> arbitrary tolerance of 1E-14.
>>
>>
>> Do you think that adding a tolerance parameter in this method
>> isUnitQuaternion() (and in its neighboors) is a good idea ?
>>
>>
>> Julien
>>
>I think a tolerance parameter which defaults to 1E-14 in my view be the best
>option. I have nothing against this magic number; I just don't think that it
>should sit in the general class Precision. I think this is also what makes
>Gilles unhappy (TBC). How about a static final double Quaternion.DEFAULT_TOL,
>instead of Precision.DEFAULT_TOL?
>Sébastien
Ok, I understand your point of view, it make sense to put specific
epsilon/tolerance value in the corresponding classes (and to justify the
value!!). We'll propose this default value in the Quaternion class (see feature
863) and will use the same mechanism in our other classes.
Best regards,
Yannick
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Adding some methods in Precision class (oacm.util)
Hi.
> >>> De : Tanguy Yannick [mailto:yannick.tan...@cnes.fr] About the default
> >>> value (1e-14), I know the tolerance is case- dependant, but some
> >>> times, we don't precisely know the order of magnitude (ex : jacobians
> >>> matrices) and it's quite practical to have a default value.
> >>
> >> Hi,
> >> A point of the discussion with Gilles in the MATH-863 (new Quaternion
> >> class) is about this magic 1E-14. ;)
> >>
> >> Consider the following methods:
> >>
> >> public Quaternion normalize() {
> >> final double norm = getNorm();
> >> if (norm >= Precision.SAFE_MIN) {
> >> return new Quaternion(q0 / norm, q1 / norm, q2 / norm, q3 /
> >> norm);
> >> } else {
> >> throw new ZeroException();
> >> }
> >> }
> >>
> >> public boolean isUnitQuaternion() {
> >> final double norm = getNorm();
> >> if (Precision.equals(norm, 1.0, Precision.EPSILON)) {
> >> return true;
> >> } else {
> >> return false;
> >> }
> >> }
> >>
> >>
> >> => There are many cases where
> >>
> >> myQuaternion.normalize().isUnitQuaternion()
> >> returns "false".
> >>
> >> The Precision.EPSILON is too small. That's why we use this "historical"
> >> arbitrary tolerance of 1E-14.
> >>
> >>
> >> Do you think that adding a tolerance parameter in this method
> >> isUnitQuaternion() (and in its neighboors) is a good idea ?
> >>
> >>
> >> Julien
> >>
> >I think a tolerance parameter which defaults to 1E-14 in my view be the best
> >option. I have nothing against this magic number; I just don't think that it
> >should sit in the general class Precision. I think this is also what makes
> >Gilles unhappy (TBC). How about a static final double
> >Quaternion.DEFAULT_TOL, instead of Precision.DEFAULT_TOL?
> >Sébastien
>
> Ok, I understand your point of view, it make sense to put specific
> epsilon/tolerance value in the corresponding classes (and to justify the
> value!!). We'll propose this default value in the Quaternion class (see
> feature 863) and will use the same mechanism in our other classes.
My point-of-view is a bit more intolerant. ;-) See my previous post (and the
forthcoming commit of the "Quaternion" class.
Then we can continue this discussion if you don't agree.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] HDFS provider
I forgot to subscribe to the dev mailing list before sending the email. I just read the responses on the archive and subscribed. I do have unit tests, but they do not use an embedded server. They are more like functional tests and require a running instance of HDFS on the system. I have not looked [yet] to see if HDFS has a mock server or one that can be embedded. My code is up at https://github.com/dlmarion/ACCUMULO-708 in case anyone is interested. I'm still working on the ticket, so I'll look to see if I can modify the unit tests. Thanks, Dave - Original Message - From: dlmar...@comcast.net To: dev@commons.apache.org Cc: dlmar...@comcast.net Sent: Wednesday, September 19, 2012 10:04:28 PM Subject: [VFS] HDFS provider I did not see a provider for HDFS on the list of supported file systems. I created a read-only HDFS provider while working on an Accumulo ticket. I was wondering if one of the devs had time to review to see if I made any glaring mistakes. I am in the process of becoming an Accumulo committer, so I'm assuming that this file system provider could be included in the VFS project if it makes sense. Thanks, Dave Marion
Re: [math] APT format for the users guide
Hello Gilles,
2012/9/20 Gilles Sadowski :
> Hi.
>
>> as I previously said, I'd like to extend the user's guide for the
>> special functions package. I am not a big fan of the xdoc format
>> currently in use, at is not easily readable. So I thought I would give
>> APT a go. Please find below the code corresponding to the current
>> "Special Functions" page.
>
> Can it be used to write math symbols/formulae?
>
Nope!
>
>> The learning curve is not steep at all (about 5 minutes!). I think
>> it's much better (even for tables, which might require a large screen
>> ;)).
>
> What's the advantage over the Wiki syntax?
>
None. I just wanted to use "standard" maven enriched text formats. APT
is supported out of the box. I am not familiar with Wiki syntax, but
I'm sure it's much, much better (as is ReSt). Do you know of any
plugin which supports it? Maven badly supports restructured text, for
example (which is why I got back to APT).
>>
>> The generated pages are identical (I've even reproduced the typo in
>> 5.4...), but for the fact that you cannot have anchors with a name
>> different from the text they refer to. So anchor {Beta} would be named
>> "Beta", and not "beta" as is currently the case. I don't think this is
>> much of an issue, as there is no reference to these anchors (I'll
>> check the other pages of the user's guide, and update them if
>> necessary).
>>
>> So, what do you think? Should I pursue, or would you like me to stay
>> with the xdoc format?
>
> My opinion is that we should figure out the kind of contents the document
> will contain, and choose the (possibly different) language(s) accordingly.
>
Basically, as already emphasized by someone else, APT is no better
than the currently used xdoc format, except that the source is
definitely readable (hence, more easily maintainable).
>> I would like to emphasize I'm not advocating for a complete switch
>> from one format to another. But since I'm going to concentrate on this
>> section of the users guide, I thought I might as well choose the
>> format which I am most comfortable with. If you do not like the idea
>> of having two different formats for the same site, please let me know.
>
> If we can agree to keep the user guide simple (i.e. limited to "To do
> , you call with , then retrieve the result as
> follows..." etc., with some verbatim code examples), then there is an
> advantage to having a source syntax that looks like plain text:
> * simple to write,
> * easy to read.
>
Yes, that's exactly my point of view. From this perspective, I don't
think xdoc does the job.
In the special package, I want to go a little further (tutorials
should not be too difficult: "to compute gamma(x), call
Gamma.gamma(x)"...), and give some tables and plots on the accuracy :
if 0 <= x <= 8, then logGamma is accurate to within 4 ulps, and so
on...
>
> But if we want to show the math that corresponds to the code, then we loose
> everything:
> * difficult to write (either including preprocessed figures or ad-hoc
>syntax)
> * impossible to read (in the source).
>
In an ideal world, we would do this also. But our time is limited...
So I'm not sure we need to worry about that for now...
>
> Loosely related to this discussion: What would you think of splitting the
> user guide into several independent tutorials? That would be more in the
> spirit of simple "howto"s (as opposed to a sort of "reference" which should
> allow for more formatting power, a la LaTeX).
> [And that would make it less strange to have different source formats.]
>
That's something to think about. As a side note, APT, although
limited, offers the possibility to produce books. That would be nice
to have these tutorials on line, and in PDF format (even better:
epub!!!).
My only worry is: our time is limited...
Best regards,
Sébastien
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] Thoughts about multi-threading
On 9/19/12 1:19 PM, Oliver Heger wrote: > Hi Phil, > > Am 18.09.2012 20:09, schrieb Phil Steitz: >> On 9/17/12 12:39 PM, Oliver Heger wrote: >>> Hi Jörg, >>> >>> many thanks for your input! >>> >>> Am 17.09.2012 10:01, schrieb Jörg Schaible: Hi Oliver, Oliver Heger wrote: > Hi, > > one limitation of the 1.x versions of [configuration] is the > incomplete > support for concurrent access to Configuration objects. In > version 2.0 > we should try to improve this. > > I have some ideas about this topic - not fully thought out - and > would > like to start a discussion. Here they are (in no specific order): > > - Thread-safety is not always required. Therefore, I would like > to take > an approach similar to the JDK Collections framework: having > basic, > unsynchronized configurations which can be turned into > thread-safe ones. Fair approach. > - Many Configuration implementations are based on a hash map. > Access to > their content could be made thread-safe by replacing the map by a > ConcurrentHashMap. You could use a protected method to instantiate the underlaying HashMap. Then you're free in overloaded Configurations.synchronizedConfiguration methods to use a derived class or a wrapper. It has also implications on subset(). >>> Or pass the map in at construction time. Using a protected method >>> to create the map would either mean that the constructor has to >>> invoke this method (problematic for subclasses which are not yet >>> fully initialized at this time) or the field cannot be made final. >>> Alternatively, there could be an abstract method getMap() >>> returning the reference to the map. >>> > - For hierarchical configurations situation is more complex. > Here we > will probably need something like a ReadWriteLock to protect > their > content. (There could be different lock implementations > including a > dummy one used by unsynchronized configurations). > > - Reloading is a major problem; at least in the way it is > implemented > now, it is very hard to get synchronization correct and > efficient. > Therefore, I would like to use a different strategy here. One > option > could be to not handle reloading in Configuration objects, but > on an > additional layer which creates such objects. > > - Other properties of configuration objects (e.g. the > throwExceptionOnMissing flag or the file name) must be taken into > account, too. In a typical use case those should not be accessed > frequently, so it is probably not an issue to always synchronize > them or > make them volatile. > > Looking forward to your input Another option would be immutability (well, apart probably from reloading). Personally I have often the use case that I do not want to offer my clients/consumers to write into the configuration. One approach can also be the JDK approach creating Collections.unmodifiableConfiguration. However, what also bugs me in the meantime is the current hard relation between the configuration object and its format. Why should I care at all in what format the configuration had been saved when I access its values? For some time I am thinking now of something in the line of: - interface Configuration: Core interfaces, only getters - interface ReloadableConfiguration extends Configuration, Reloadable - class BaseConfiguration: In memory, implements all the stuff for interpolation and the setters - interface ConfigurationSource: Core interface to load (and probably save a configuration) - class PropertiesConfigurationSource: Concrete implementation that loads a properties file and creates a BaseConfiguration This approach offers immutability for the Configuration itself and also allows Serializability. Format is separated completely from the configuration functionality. I know, this looks more like Configuration 3.0 ... ;-) >>> I really like this approach. I was also thinking about separating >>> loading and saving from core Configuration classes. However, I >>> fear such an approach will make it difficult to preserve the >>> format of a configuration. E.g. XMLConfiguration currently stores >>> the XML document it was loaded from. So when saved to disk, result >>> looks much like the original document. >>> >>> Read-only configurations is also an interesting topic. >> >> This obviously makes the concurrency problem easier :) >> >> Apart from this case, it would be good to agree on exactly what it >> means for [configuration] to be threadsafe. Is it basically the >> semantics of ConcurrentHashmap? Or are there sequencing / event >> serialization constraints?
[continuum] BUILD FAILURE: Apache Commons - Commons Math -
Group (shared) Maven 2 Build Definition (Java 1.5) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Continuum-Build-Host: vmbuild X-Continuum-Project-Id: 97 X-Continuum-Project-Name: Commons Math Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=24844&projectId=97 Build statistics: State: Failed Previous State: Ok Started at: Thu 20 Sep 2012 19:22:50 + Finished at: Thu 20 Sep 2012 19:23:22 + Total time: 31s Build Trigger: Schedule Build Number: 990 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_30" Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_30 Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: "linux" version: "2.6.32-41-server" arch: "amd64" Family: "unix" SCM Changes: Changed: celestin @ Thu 20 Sep 2012 18:50:45 + Comment: MATH-854 - filled the "throws" clause of Array2DRowRealMatrix, - corrected some method signatures in RealMatrix and AbstractRealMatrix accordingly, - in AbstractRealMatrix, removed "abstract implementations" of some methods specified in interface RealMatrix, as they serve no purpose. Files changed: /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/AbstractRealMatrix.java ( 1388154 ) /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/Array2DRowRealMatrix.java ( 1388154 ) /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/RealMatrix.java ( 1388154 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Group (shared) Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 0 Failures: 0 Errors: 0 Total time: 0.0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] APT format for the users guide
On 9/20/12 12:01 PM, Sébastien Brisard wrote:
> Hello Gilles,
>
> 2012/9/20 Gilles Sadowski :
>> Hi.
>>
>>> as I previously said, I'd like to extend the user's guide for the
>>> special functions package. I am not a big fan of the xdoc format
>>> currently in use, at is not easily readable. So I thought I would give
>>> APT a go. Please find below the code corresponding to the current
>>> "Special Functions" page.
>> Can it be used to write math symbols/formulae?
>>
> Nope!
Can you do the escaping necessary to get MathJax to work embedded?
>
>>> The learning curve is not steep at all (about 5 minutes!). I think
>>> it's much better (even for tables, which might require a large screen
>>> ;)).
>> What's the advantage over the Wiki syntax?
>>
> None. I just wanted to use "standard" maven enriched text formats. APT
> is supported out of the box. I am not familiar with Wiki syntax, but
> I'm sure it's much, much better (as is ReSt). Do you know of any
> plugin which supports it? Maven badly supports restructured text, for
> example (which is why I got back to APT).
>
>>> The generated pages are identical (I've even reproduced the typo in
>>> 5.4...), but for the fact that you cannot have anchors with a name
>>> different from the text they refer to. So anchor {Beta} would be named
>>> "Beta", and not "beta" as is currently the case. I don't think this is
>>> much of an issue, as there is no reference to these anchors (I'll
>>> check the other pages of the user's guide, and update them if
>>> necessary).
>>>
>>> So, what do you think? Should I pursue, or would you like me to stay
>>> with the xdoc format?
>> My opinion is that we should figure out the kind of contents the document
>> will contain, and choose the (possibly different) language(s) accordingly.
>>
> Basically, as already emphasized by someone else, APT is no better
> than the currently used xdoc format, except that the source is
> definitely readable (hence, more easily maintainable).
I agree with this and have thought about suggesting this move in the
past, just never had time or sufficient motivation to do it.
>
>>> I would like to emphasize I'm not advocating for a complete switch
>>> from one format to another. But since I'm going to concentrate on this
>>> section of the users guide, I thought I might as well choose the
>>> format which I am most comfortable with. If you do not like the idea
>>> of having two different formats for the same site, please let me know.
>> If we can agree to keep the user guide simple (i.e. limited to "To do
>> , you call with , then retrieve the result as
>> follows..." etc., with some verbatim code examples), then there is an
>> advantage to having a source syntax that looks like plain text:
>> * simple to write,
>> * easy to read.
>>
> Yes, that's exactly my point of view. From this perspective, I don't
> think xdoc does the job.
> In the special package, I want to go a little further (tutorials
> should not be too difficult: "to compute gamma(x), call
> Gamma.gamma(x)"...), and give some tables and plots on the accuracy :
> if 0 <= x <= 8, then logGamma is accurate to within 4 ulps, and so
> on...
You can do all of this with xdoc, it is just painful. You need to
use html syntax for tables. The [dbcp] docs have some examples
showing the pain.
>
>> But if we want to show the math that corresponds to the code, then we loose
>> everything:
>> * difficult to write (either including preprocessed figures or ad-hoc
>>syntax)
>> * impossible to read (in the source).
>>
> In an ideal world, we would do this also. But our time is limited...
> So I'm not sure we need to worry about that for now...
I am +1 for playing with MathJax embedded where it makes sense.
>
>> Loosely related to this discussion: What would you think of splitting the
>> user guide into several independent tutorials? That would be more in the
>> spirit of simple "howto"s (as opposed to a sort of "reference" which should
>> allow for more formatting power, a la LaTeX).
>> [And that would make it less strange to have different source formats.]
>>
> That's something to think about. As a side note, APT, although
> limited, offers the possibility to produce books. That would be nice
> to have these tutorials on line, and in PDF format (even better:
> epub!!!).
>
> My only worry is: our time is limited...
I would say stay focused on the simple goals of the guide as it
exists today. One thing to check is that generating some sources
from apt and some from xdoc, we do not have big pain generating the
integrated site and we can maintain a single table of contents page.
Phil
>
> Best regards,
> Sébastien
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For addition
Re: [configuration] Thoughts about multi-threading
>>> >>> This obviously makes the concurrency problem easier :) >>> >>> Apart from this case, it would be good to agree on exactly what it >>> means for [configuration] to be threadsafe. Is it basically the >>> semantics of ConcurrentHashmap? Or are there sequencing / event >>> serialization constraints? For example, suppose the sequence below >>> happens >>> Thread A start add property >>> Thread B start clear >>> Thread A notify property change >>> Thread B notify clear >>> Thread B clear map >>> Thread A update map >>> >>> Is it OK for this sequence to happen? Is it OK for A's add to trump >>> B's clear even though B's activation started later and B's >>> notification was later? >> >> This is a very good point, I did not think about this. It would be >> very confusing for an event listener to receive a clear event and >> then find out that the configuration is not empty. >> >> So I guess it is too naive to simply replace the plain map by a >> concurrent map to gain thread-safety. We will then probably have >> to use a read-write lock for map-based configurations, too. Well, >> this is not too bad. The only thing which worries me a bit is that >> we have to call event listeners while the lock is held. This is an >> anti-pattern described by Bloch: "Don't call an alien method with >> a lock held!". Does anybody has an idea how we could prevent this? > >Interesting problem. Unfortunately, I don't think you can enforce >the serializability invariant (no interleaving as above) without >some [configuration] thread holding a lock while notification >happens. You could queue notify-update tasks so add/update >invocations don't block; but whatever thread actually executes the >tasks would have to lock takes from the queue while notifies >complete. That might not be that bad, since you could continue to >services reads (of yet-to-be-updated data) and queue updates while >the foreign lock was held; but it still violates the maxim, with the >consequence that a hung listener could stop updates from happening. Is serializability what's desired? Or is it consistency? I can imagine a situation where multiple properties must enforce some invariant relationship. The producer would like to be able to hold off notifying the property consumers before the next property change fixes the invariant constraint violation. Likewise the consumer might want a set which is invariant between applying the first property and the last property. chas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-dbcp has an issue affecting its community integration. This issue affects 18 projects, and has been outstanding for 87 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-dbcp : Object Pooling - db-ddlutils : Easy-to-use component for working with Database Definition (... - jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-dbcp : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-tomcat-jk : Connectors to various web servers - javax.el : Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for ... - javax.servlet : Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for ... - javax.servlet.jsp : Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for ... - solr : Java Based Search Engine - solr-test : Java Based Search Engine - tomcat-tc6 : Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for ... - tomcat-tc7.0.x : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... - tomcat-tc7.0.x-dbcp : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... - tomcat-tc7.0.x-test : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... - tomcat-trunk : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... - tomcat-trunk-dbcp : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... - tomcat-trunk-test : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-dbcp.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/gump_work/build_commons-dbcp-1.x_commons-dbcp.html Work Name: build_commons-dbcp-1.x_commons-dbcp (Type: Build) Work ended in a state of : Failed Elapsed: 10 secs Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only -Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml dist [Working Directory: /srv/gump/public/workspace/commons-dbcp-1.x] CLASSPATH: /usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/junit/dist/junit-21092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-21092012.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/public/workspace/commons-pool-1.x/dist/commons-pool-1.6.1-SNAPSHOT.jar - [javac]^ [javac] where T is a type-variable: [javac] T extends Object declared in method getObject(String,Class) [javac] /srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingConnection.java:65: error: DelegatingConnection is not abstract and does not override abstract method getNetworkTimeout() in Connection [javac] public class DelegatingConnection extends AbandonedTrace [javac]^ [javac] /srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java:38: error: DelegatingDatabaseMetaData is not abstract and does not override abstract method generatedKeyAlwaysReturned() in DatabaseMetaData [javac] public class DelegatingDatabaseMetaData extends AbandonedTrace [javac]^ [javac] /srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingResultSet.java:61: error: DelegatingResultSet is not abstract and does not override abstract method getObject(String,Class) in ResultSet [javac] public class DelegatingResultSet extends Aba
[GUMP@vmgump]: Project commons-dbcp2 (in module apache-commons) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-dbcp2 has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 87 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp2 : Database Connection Pool
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-dbcp2-*[0-9T].jar] identifier set to project
name
-INFO- Failed with reason build failed
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/gump_work/build_apache-commons_commons-dbcp2.html
Work Name: build_apache-commons_commons-dbcp2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 8 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true
-Dbuild.sysclasspath=only
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml
dist
[Working Directory: /srv/gump/public/workspace/apache-commons/dbcp]
CLASSPATH:
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/apache-commons/dbcp/dist/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/packages/jdbc2_0/jdbc2_0-stdext.jar:/srv/gump/public/workspace/junit/dist/junit-21092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-21092012.jar:/srv/gump/public/workspace/apache-commons/pool/dist/commons-pool2-2.0-SNAPSHOT.jar
-
[mkdir] Created dir:
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] Compiling 52 source files to
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/BasicDataSource.java:52:
error: BasicDataSource is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[javac] public class BasicDataSource implements DataSource {
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingConnection.java:65:
error: DelegatingConnection is not abstract and does not override abstract
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingStatement.java:46:
error: DelegatingStatement is not abstract and does not override abstract
method isCloseOnCompletion() in Statement
[javac] public class DelegatingStatement extends AbandonedTrace implements
Statement {
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingPreparedStatement.java:57:
error: DelegatingPreparedStatement is not abstract and does not override
abstract method isCloseOnCompletion() in Statement
[javac] public class DelegatingPreparedStatement extends DelegatingStatement
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingCallableStatement.java:58:
error: DelegatingCallableStatement is not abstract and does not override
abstract method getObject(String,Class) in CallableStatement
[javac] public class DelegatingCallableStatement extends
DelegatingPreparedStatement
[javac]^
[javac] where T is a type-variable:
[javac] T extends Object declared in method
getObject(String,Class)
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingDatabaseMetaData.java:36:
error: DelegatingDatabaseMetaData is not abstract and does not override
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public class
Re: [math] APT format for the users guide
Hi Phil,
2012/9/20 Phil Steitz :
> On 9/20/12 12:01 PM, Sébastien Brisard wrote:
>> Hello Gilles,
>>
>> 2012/9/20 Gilles Sadowski :
>>> Hi.
>>>
as I previously said, I'd like to extend the user's guide for the
special functions package. I am not a big fan of the xdoc format
currently in use, at is not easily readable. So I thought I would give
APT a go. Please find below the code corresponding to the current
"Special Functions" page.
>>> Can it be used to write math symbols/formulae?
>>>
>> Nope!
>
> Can you do the escaping necessary to get MathJax to work embedded?
>
That you can. You just need to tell maven to add the required
javascript snippet in the header of the generated XHTML files.
>>
The learning curve is not steep at all (about 5 minutes!). I think
it's much better (even for tables, which might require a large screen
;)).
>>> What's the advantage over the Wiki syntax?
>>>
>> None. I just wanted to use "standard" maven enriched text formats. APT
>> is supported out of the box. I am not familiar with Wiki syntax, but
>> I'm sure it's much, much better (as is ReSt). Do you know of any
>> plugin which supports it? Maven badly supports restructured text, for
>> example (which is why I got back to APT).
>>
The generated pages are identical (I've even reproduced the typo in
5.4...), but for the fact that you cannot have anchors with a name
different from the text they refer to. So anchor {Beta} would be named
"Beta", and not "beta" as is currently the case. I don't think this is
much of an issue, as there is no reference to these anchors (I'll
check the other pages of the user's guide, and update them if
necessary).
So, what do you think? Should I pursue, or would you like me to stay
with the xdoc format?
>>> My opinion is that we should figure out the kind of contents the document
>>> will contain, and choose the (possibly different) language(s) accordingly.
>>>
>> Basically, as already emphasized by someone else, APT is no better
>> than the currently used xdoc format, except that the source is
>> definitely readable (hence, more easily maintainable).
>
> I agree with this and have thought about suggesting this move in the
> past, just never had time or sufficient motivation to do it.
>>
I would like to emphasize I'm not advocating for a complete switch
from one format to another. But since I'm going to concentrate on this
section of the users guide, I thought I might as well choose the
format which I am most comfortable with. If you do not like the idea
of having two different formats for the same site, please let me know.
>>> If we can agree to keep the user guide simple (i.e. limited to "To do
>>> , you call with , then retrieve the result as
>>> follows..." etc., with some verbatim code examples), then there is an
>>> advantage to having a source syntax that looks like plain text:
>>> * simple to write,
>>> * easy to read.
>>>
>> Yes, that's exactly my point of view. From this perspective, I don't
>> think xdoc does the job.
>> In the special package, I want to go a little further (tutorials
>> should not be too difficult: "to compute gamma(x), call
>> Gamma.gamma(x)"...), and give some tables and plots on the accuracy :
>> if 0 <= x <= 8, then logGamma is accurate to within 4 ulps, and so
>> on...
>
> You can do all of this with xdoc, it is just painful. You need to
> use html syntax for tables. The [dbcp] docs have some examples
> showing the pain.
>
Yes, even the (fairly simple) doc we have is a pain to read.
>>
>>> But if we want to show the math that corresponds to the code, then we loose
>>> everything:
>>> * difficult to write (either including preprocessed figures or ad-hoc
>>>syntax)
>>> * impossible to read (in the source).
>>>
>> In an ideal world, we would do this also. But our time is limited...
>> So I'm not sure we need to worry about that for now...
>
> I am +1 for playing with MathJax embedded where it makes sense.
>
I also think it would be a good option, as I don't think our needs for
mathematical typesetting are so high. It would be nice if we could
configure the site to fall back to LaTeX + dvipng when MathJax is not
available. I'm not sure how you do that, but it should be possible (I
think Wikipedia offers this possibility).
>>
>>> Loosely related to this discussion: What would you think of splitting the
>>> user guide into several independent tutorials? That would be more in the
>>> spirit of simple "howto"s (as opposed to a sort of "reference" which should
>>> allow for more formatting power, a la LaTeX).
>>> [And that would make it less strange to have different source formats.]
>>>
>> That's something to think about. As a side note, APT, although
>> limited, offers the possibility to produce books. That would be nice
>> to have these tutorials on line, and in PDF format (even better:
>> epub!!!).
>>
>> My only worry is: our time is limited...
Re: [math] APT format for the users guide
Hello again,
Gilles mentioned Wiki syntax, and I just realized that Doxia has
built-in support for TWiki. I will give it a go, but the answer should
probably be that it's better than apt (for example, you can use html
tags if you want to).
So maybe what in a few days, I'll be writing the same email, replacing
every occurence of apt with TWiki. I'm experimenting, for the time
being...
Sébastien
2012/9/21 Sébastien Brisard :
> Hi Phil,
>
> 2012/9/20 Phil Steitz :
>> On 9/20/12 12:01 PM, Sébastien Brisard wrote:
>>> Hello Gilles,
>>>
>>> 2012/9/20 Gilles Sadowski :
Hi.
> as I previously said, I'd like to extend the user's guide for the
> special functions package. I am not a big fan of the xdoc format
> currently in use, at is not easily readable. So I thought I would give
> APT a go. Please find below the code corresponding to the current
> "Special Functions" page.
Can it be used to write math symbols/formulae?
>>> Nope!
>>
>> Can you do the escaping necessary to get MathJax to work embedded?
>>
> That you can. You just need to tell maven to add the required
> javascript snippet in the header of the generated XHTML files.
>
>>>
> The learning curve is not steep at all (about 5 minutes!). I think
> it's much better (even for tables, which might require a large screen
> ;)).
What's the advantage over the Wiki syntax?
>>> None. I just wanted to use "standard" maven enriched text formats. APT
>>> is supported out of the box. I am not familiar with Wiki syntax, but
>>> I'm sure it's much, much better (as is ReSt). Do you know of any
>>> plugin which supports it? Maven badly supports restructured text, for
>>> example (which is why I got back to APT).
>>>
> The generated pages are identical (I've even reproduced the typo in
> 5.4...), but for the fact that you cannot have anchors with a name
> different from the text they refer to. So anchor {Beta} would be named
> "Beta", and not "beta" as is currently the case. I don't think this is
> much of an issue, as there is no reference to these anchors (I'll
> check the other pages of the user's guide, and update them if
> necessary).
>
> So, what do you think? Should I pursue, or would you like me to stay
> with the xdoc format?
My opinion is that we should figure out the kind of contents the document
will contain, and choose the (possibly different) language(s) accordingly.
>>> Basically, as already emphasized by someone else, APT is no better
>>> than the currently used xdoc format, except that the source is
>>> definitely readable (hence, more easily maintainable).
>>
>> I agree with this and have thought about suggesting this move in the
>> past, just never had time or sufficient motivation to do it.
>>>
> I would like to emphasize I'm not advocating for a complete switch
> from one format to another. But since I'm going to concentrate on this
> section of the users guide, I thought I might as well choose the
> format which I am most comfortable with. If you do not like the idea
> of having two different formats for the same site, please let me know.
If we can agree to keep the user guide simple (i.e. limited to "To do
, you call with , then retrieve the result as
follows..." etc., with some verbatim code examples), then there is an
advantage to having a source syntax that looks like plain text:
* simple to write,
* easy to read.
>>> Yes, that's exactly my point of view. From this perspective, I don't
>>> think xdoc does the job.
>>> In the special package, I want to go a little further (tutorials
>>> should not be too difficult: "to compute gamma(x), call
>>> Gamma.gamma(x)"...), and give some tables and plots on the accuracy :
>>> if 0 <= x <= 8, then logGamma is accurate to within 4 ulps, and so
>>> on...
>>
>> You can do all of this with xdoc, it is just painful. You need to
>> use html syntax for tables. The [dbcp] docs have some examples
>> showing the pain.
>>
> Yes, even the (fairly simple) doc we have is a pain to read.
>
>>>
But if we want to show the math that corresponds to the code, then we loose
everything:
* difficult to write (either including preprocessed figures or ad-hoc
syntax)
* impossible to read (in the source).
>>> In an ideal world, we would do this also. But our time is limited...
>>> So I'm not sure we need to worry about that for now...
>>
>> I am +1 for playing with MathJax embedded where it makes sense.
>>
> I also think it would be a good option, as I don't think our needs for
> mathematical typesetting are so high. It would be nice if we could
> configure the site to fall back to LaTeX + dvipng when MathJax is not
> available. I'm not sure how you do that, but it should be possible (I
> think Wikipedia offers this possibility).
>
>>>
Loosely related to this discussion: What would you think of splitting the
user gu
[math] Documentation: xdoc, apt and twiki pros and cons
Hello, I've been playing around with these three formats. Here are my thoughts xdoc + already used by the existing doc, + possible to embed XHTML tags, - like all xml based languages, it is difficult to read, especially when it comes to tables. apt + increased readability, - not possible to embed XHTML tags. twiki + increased readability, + possible to embed XHTML tags, - not really superior to apt, - last version dates back 2007, - I could not find the way to comment out some text, so I could not include the license in my test file. Looking up the web, should work; well, I could not make it work. - there is no syntax to specify the title of the page (in the sense of the ... XHTML tags). Using XHTML embedded code like ... does not work, which was to be expected, since the doc states that the embedded code would go in the ... section. So, all in all, I would still recommend apt. Sébastien PS: all three options are very easy to learn. twiki requires the following alteration of the pom.xml in the ... section org.apache.maven.plugins maven-site-plugin org.apache.maven.doxia doxia-module-twiki 1.2 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
and has been outstanding for 92 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-digester3 : XML to Java Object Configuration
- commons-digester3-test : Apache Commons
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-digester3-*[0-9T].jar] identifier set to
project name
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/apache-commons/digester/pom.xml
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
Work Name: build_apache-commons_commons-digester3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 59 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
package
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn
--non-interactive info
[INFO] Working directory:
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildNumber: ?? at timestamp: 1348199686643
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn
--non-interactive info
[INFO] Working directory:
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 5 source files to
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/src/test/resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 3 source files to
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/test-classes
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/image")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/item")
>
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[ERROR] error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[INFO] 2 errors
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annota
[GUMP@vmgump]: Project commons-chain2 (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-chain2 has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 109 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-chain2 : GoF "Chain of Responsibility" pattern Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-chain2-*[0-9T].jar] identifier set to project name -DEBUG- Sole pom output [pom.xml] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/chain/pom.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/gump_work/build_apache-commons_commons-chain2.html Work Name: build_apache-commons_commons-chain2 (Type: Build) Work ended in a state of : Failed Elapsed: 60 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/chain] M2_HOME: /opt/maven2 - [INFO] Building war: /srv/gump/public/workspace/apache-commons/chain/apps/cookbook-examples/target/chain-cookbook-examples-2.0-SNAPSHOT.war [INFO] [INFO] Building Apache Commons Chain :: Distribution Packages [INFO]task-segment: [package] [INFO] [INFO] snapshot org.apache.commons:commons-chain2-configuration:2.0-SNAPSHOT: checking for updates from apache.snapshots Downloading: http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.pom [INFO] Unable to find resource 'org.apache.commons:commons-chain2-configuration:pom:2.0-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) Downloading: http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.jar [INFO] Unable to find resource 'org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.commons -DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT 2) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT from the specified remote repositories: gump-central (http://localhost:8192/maven2), gump-apache.snapshots (http://localhost:8192/repo/m2-snapshot-repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 58 seconds [INFO] Finished at: Fri Sep 21 05:06:26 UTC 2012 [INFO] Final Memory: 113M/241M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/atom
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 92 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.071 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.057 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.036 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.336 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.053 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 16 seconds [INFO] Finished at: Fri Sep 21 05:40:24 UTC 2012 [INFO] Final Memory: 25M/61M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.or
[GUMP@vmgump]: Project commons-dbutils (in module apache-commons) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-dbutils has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 87 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbutils : Commons DbUtils
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-dbutils-*[0-9T].jar] identifier set to
project name
-INFO- Optional dependency mockito failed with reason build failed
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/dbutils/pom.xml
-INFO- Project Reports in:
/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports
-WARNING- No directory
[/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports]
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/gump_work/build_apache-commons_commons-dbutils.html
Work Name: build_apache-commons_commons-dbutils (Type: Build)
Work ended in a state of : Failed
Elapsed: 18 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml package
[Working Directory: /srv/gump/public/workspace/apache-commons/dbutils]
M2_HOME: /opt/maven2
-
Downloading:
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.pom
1K downloaded (mockito-core-1.9.0.pom)
Downloading:
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.pom
479b downloaded (hamcrest-all-1.1.pom)
Downloading:
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.jar
Downloading:
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.jar
273K downloaded (hamcrest-all-1.1.jar)
1381K downloaded (mockito-core-1.9.0.jar)
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
main:
[copy] Copying 2 files to
/srv/gump/public/workspace/apache-commons/dbutils/target/apidocs/META-INF
[INFO] Executed tasks
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildNumber: ?? at timestamp: 1348206395541
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/srv/gump/public/workspace/apache-commons/dbutils/src/main/resources
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 28 source files to
/srv/gump/public/workspace/apache-commons/dbutils/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
error: DriverProxy is not abstract and does not override abstract method
getParentLogger() in Driver
[INFO] 1 error
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
error: DriverProxy is not abstract and does not override abstract method
getParentLogger() in Driver
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
