[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 86 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: 23 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.244 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.071 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 14 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-18092012.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: Tue Sep 18 07:26:14 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 1318092012, vmgump.apache.org:vmgump:1318092012
Gump E-mail Identifier (unique within run) #59.
--
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: [all] xdoc vs. apt
Le 2012-09-18 07:46, Sébastien Brisard a écrit : Hi, Hi Sébastien, 2012/9/18 Sébastien Brisard : Hi, thanks for these answers. I agree that apt does not seem much better than xdoc, but it at least offers table formatting and so on. So can anyone recommend a good format? Otherwise, I'm quite happy with xhtml. An option I'm going to look at at work is sphinx [1]. It has become widely spread in the python community and is based on the restructured text format. More importantly (for Commons-Math), it supports formulas, either with dvipng (requires a local installation of LaTeX), or Mathjax (which is pretty good, and could also be used in xhtml). Having something compatible with Mathjax would be a tremendous step forward for [math]. I would really love to see this happen! Formulas based on dvipng are really not good. There are always problems of font sizes (for inline or display formulas, for some browsers like mobile devices) and they are not friendly with parsers like search engines or screen readers for visually impaired people. I can report on my experiments with this format. I am really interested in reading about this. On a side note, for another project I am involved in, do you know if sphinx is compatible with the chiliproject forge? best regards, Luc Best regards, Sébastien [1] http://sphinx.pocoo.org/ I forgot to add that there are apparently maven plugins for Sphinx... 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 additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] xdoc vs. apt
Hi Luc, 2012/9/18 luc : > Le 2012-09-18 07:46, Sébastien Brisard a écrit : >> >> Hi, > > > Hi Sébastien, > >> >> 2012/9/18 Sébastien Brisard : >>> >>> Hi, >>> thanks for these answers. >>> I agree that apt does not seem much better than xdoc, but it at least >>> offers table formatting and so on. >>> So can anyone recommend a good format? Otherwise, I'm quite happy with >>> xhtml. >>> >>> An option I'm going to look at at work is sphinx [1]. It has become >>> widely spread in the python community and is based on the restructured >>> text format. >>> More importantly (for Commons-Math), it supports formulas, either with >>> dvipng (requires a local installation of LaTeX), or Mathjax (which is >>> pretty good, and could also be used in xhtml). > > > Having something compatible with Mathjax would be a tremendous step forward > for > [math]. I would really love to see this happen! Formulas based on dvipng are > really not good. There are always problems of font sizes (for inline or > display > formulas, for some browsers like mobile devices) and they are not friendly > with > parsers like search engines or screen readers for visually impaired people. > I agree, it's only a "better-than-nothing" solution. > >>> I can report on my experiments with this format. > > > I am really interested in reading about this. On a side note, for another > project > I am involved in, do you know if sphinx is compatible with the chiliproject > forge? > I wouldn't know, as I've never heard of chiliproject forge... However, Sphinx really seems to be getting bigger and bigger : the whole doc of Python is written (I understand) with sphinx. Best regards, Sébastien PS: there are other ways to play around with MathML. If you're interested, I have written a taglet to include MathML in Javadoc. However, *.mml files become very verbose, I like the MathJax approach (LaTeX is more compact). Using standard javadoc commands (adding a line in the header of footer of each page), you can use MathJax in the javadoc, if you're ever interested... - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] About MATH-852: Improvements to the Developer's Guide
On Tue, Sep 18, 2012 at 07:45:24AM +0200, Sébastien Brisard wrote: > Hi, > I'd like to make a move on this issue. Does everyone agree with what's > already written in this ticket (not much, I'm afraid). > Does anyone want to add anything to the formatting section? This > should be something we are particularly attached to, and that can't be > revealed by the checkstyle report. > > Also, we could add some guidance on coding practices (prefer final > over non final variables/fields, and so on). Yes, certainly: * "final" must be used when the value of the variable will not change. * Variables should not be deprived of the "final" keyword just so that they be "recycled" (i.e. use different variables when they mean different things). [Again, "BOBYQAOptimizer" was a "nice" example of not following that latter rule.] > > Any ideas? I've updated the JIRA ticket with my preferences. Thanks for advancing this issue, Gilles > > Thanks in advance, > Sébastien > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] xdoc vs. apt
I did the whole Flume web site in Sphinx - http://flume.apache.org. It works great for documentation but isn't really designed to build a web site - although you can. The Maven plugin has a few gotchas at the moment: 1 - it has a bug that causes it to use a lot of memory on multi-module builds 2. It can't effectively render PDFs (you can manually do this with rst2pdf). Ralph On Sep 17, 2012, at 10:39 PM, Sébastien Brisard wrote: > Hi, > thanks for these answers. > I agree that apt does not seem much better than xdoc, but it at least > offers table formatting and so on. > So can anyone recommend a good format? Otherwise, I'm quite happy with xhtml. > > An option I'm going to look at at work is sphinx [1]. It has become > widely spread in the python community and is based on the restructured > text format. > More importantly (for Commons-Math), it supports formulas, either with > dvipng (requires a local installation of LaTeX), or Mathjax (which is > pretty good, and could also be used in xhtml). > I can report on my experiments with this format. > > Best regards, > Sébastien > > [1] http://sphinx.pocoo.org/ > > > - > 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 additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] xdoc vs. apt
Hi Gilles, > > As you both point out indirectly, the Javadoc system is not exactly suitable > to compose a scientific document. But I remind that its main goal is to > explain the API of a code, not to explain the science that supports the > implementation. > As a matter of fact, I was talking about the user's guide, not the Javadoc. But you have a good point on this too, below! > > Of course, we can provide some additional hints about the scientific > background, but I do not think that we should go too far in that direction > within the Javadoc. Attempting to write complex stuff (e.g. equations) using > either HTML tables or ASCII art (or any script that amounts to making it > impossible to read the equations directly within the source) would render > the comments useless within the source, forcing the developer to read the > formatted doc if he actually needs that information. > It will also make it a two-step process to check whether the doc is in > agreement with the code. [A second step that will easily be "forgotten".] > > If people are interested to provide more in-depth usage and background info, > I suggest that we do it only in the user guide. > My opinion is that such a document should be written in LaTeX (thus made > "universally" available as a PDF file) with all the formatting freedom that > comes with it. > > Tutorials should be limited to illustrating selected parts of the library > without using fancy formatting tools. [It's not that I don't like those > tools, but I do not think that CM has the resources to maintain the complex > documents that the API documentation is going to become.] > So, I guess you mean the online User's guide should essentially be a tutorial, while reference material should be provided in a LaTeX file? I think you have a very good point with maintenance, sorry I have overlooked that... In you opinion, would you think that reference values (in ulps) for the accuracy of special functions should be provided online in the website, or as a separate document ? I would favor the online website. If I feel the need for mathematical formulas, then this part could go in a separate LaTeX file. What do you think? Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] xdoc vs. apt
Hi Luc. > > [...] > >> > >>So at least we have to think a little about it. > >> > >Another option would be this: since maven-site works with strict > >xhtml > >(unlike javadoc), we can embed MathML code in our pages. I'm not sure > >how we would do it in xdoc or apt, but we can certainly write our > >user's guide in xhtml (which would not make much of a difference as > >compared to xdoc). I know MathML is (very) verbose, but our site > >would > >then be fully self-sufficient. One approach I use quite consistently > >is to write MathML objects in *.mml files, which are included in the > >xhtml file. > > Please, don't go that way. MathML is really tough to write and to > read. It is something > that should be done only by tools, it's not an authoring environment. > > Really, MathJax (I think Gilles was the first to suggest it years > ago) Sorry, wrong pick again. ;-) IIRC, I once proposed to use something that would have allowed to insert LaTeX snippets in the Javadoc. [But I've now changed my mind (see my previous message).] > is a very good > option with its support to simpler syntax than MathML. Perhaps the > concerns I have > about hosting the files are stupid. Perhaps even if we decide to > host these files > it would be easy to do use local files for our own servers and have > the regular maven > build for users use the public cdn files. > > This is clearly related also to our migration to svnpubsub as this > will for sure > force us to change other things too. Nobody (among CM contributors) had the time to have a look at what needs to be done about this "svnpubsub" in order to update the CM part of the site. IMHO, this tells something about how risky it is to depend on tools that only a very few of us will have the time to learn. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-exec-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-exec-test 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-exec-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-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/exec/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html Work Name: build_apache-commons_commons-exec-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 24 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/exec] M2_HOME: /opt/maven2 - Running org.apache.commons.exec.util.StringUtilTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.exec.util.MapUtilTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.exec.DefaultExecutorTest FOO.. gdal_translate HDF5:"/home/kk/grass/data/4404.he5"://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif FOO.. PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.024 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.031 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.022 ms Process completed in 2003 millis; below is its output Process timed out and was killed by watchdog. org.apache.commons.exec.ExecuteException: Process exited with an error: 143 (Exit value: 143) Process completed in 2003 millis; below is its output Process timed out and was killed. Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Executing [sh, -c, src/test/scripts/invoker.sh] invoker.sh -- going to start daemon process invoker.sh -- daemon process was started cd: 21: can't cd to ../../../target Process completed in 8037 millis; above is its output Processes terminated: 6 killed: 0 Multiplier: 1 MaxRetries: 180 Elapsed (avg ms): 1004 Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.744 sec <<< FAILURE! Results : Failed tests: testExec_60(org.apache.commons.exec.DefaultExecutorTest) Tests run: 95, Failures: 1, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 23 seconds [INFO] Finished at: Tue Sep 18 14:23:00 UTC 2012 [INFO] Final Memory: 28M/67M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 05001218092012, vmgump.apache.org:vmgump:05001218092012 Gump E-mail Identifier (unique within run) #1. -- 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: [all] xdoc vs. apt
On 9/18/12 6:47 AM, Sébastien Brisard wrote: > Hi Gilles, > >> As you both point out indirectly, the Javadoc system is not exactly suitable >> to compose a scientific document. But I remind that its main goal is to >> explain the API of a code, not to explain the science that supports the >> implementation. >> > As a matter of fact, I was talking about the user's guide, not the > Javadoc. But you have a good point on this too, below! > >> Of course, we can provide some additional hints about the scientific >> background, but I do not think that we should go too far in that direction >> within the Javadoc. Attempting to write complex stuff (e.g. equations) using >> either HTML tables or ASCII art (or any script that amounts to making it >> impossible to read the equations directly within the source) would render >> the comments useless within the source, forcing the developer to read the >> formatted doc if he actually needs that information. >> It will also make it a two-step process to check whether the doc is in >> agreement with the code. [A second step that will easily be "forgotten".] >> >> If people are interested to provide more in-depth usage and background info, >> I suggest that we do it only in the user guide. >> My opinion is that such a document should be written in LaTeX (thus made >> "universally" available as a PDF file) with all the formatting freedom that >> comes with it. >> >> Tutorials should be limited to illustrating selected parts of the library >> without using fancy formatting tools. [It's not that I don't like those >> tools, but I do not think that CM has the resources to maintain the complex >> documents that the API documentation is going to become.] >> > So, I guess you mean the online User's guide should essentially be a > tutorial, while reference material should be provided in a LaTeX file? > I think you have a very good point with maintenance, sorry I have > overlooked that... > > In you opinion, would you think that reference values (in ulps) for > the accuracy of special functions should be provided online in the > website, or as a separate document ? > I would favor the online website. If I feel the need for mathematical > formulas, then this part could go in a separate LaTeX file. > What do you think? Let me ask a naive question: is it possible to embed (and easily maintain) hyperlinks in LaTex? I suspect the answer is yes, but I have never done it personally. I would prefer to keep the User Guide as one document / set of hyperlinked documents and have it function more or less as it does now - explain enough of the mathematical background so people understand what the APIs mean and enough code samples so they can quickly figure out how to use them. The first goal overlaps with the javadoc; but in the User Guide a more expository approach can be taken. When combined with examples this is helpful. We seem to have three options: 0) Just keep chugging along with the clunky xdoc and its limitations 1) Use MathJax to basically embed TeX formulas 2) Commit TeX sources and just generate and host pdfs I am not sure the hosting issue is that big a deal on 1), or the performance or lack of online access; but I agree these are negatives. If we can get links to work (especially links to the javadoc), I would be open to 2). The problem there is the monstrous task of translating everything and also the requirement that everyone contributing to the guide be happy with TeX. Most likely the second item is a net positive for most [math] people vis a vis xdoc ;) If the links can be reasonably made to work and maintain, I would lean toward 2). I am not averse to 1) either though and it does have the advantage of being something we could bring in incrementally. Another thing to think about here is which among these is most likely to attract contributions to the documentation. Part of the motivation for adding the User Guide in the first place and to have it included in the site build was to encourage people to contribute to the documentation. We have never really succeeded in getting contributions just to the Guide - i.e., we generally end up having to update it as we prepare for releases as sort of an afterthought. Other projects sometimes attract doco contributors who provide a huge service to the community improving the user documentation. Unfortunately, none of the options above look that appealing from that standpoint. Possibly 2) is the best. I would be interested to hear from others in the community who might be cajoled into helping out with this. Phil > 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 additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] Thoughts about multi-threading
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? 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? Phil > > But I think you are right,
Re: [all] xdoc vs. apt
Hi Phil, thanks for your thoughts! 2012/9/18 Phil Steitz : > On 9/18/12 6:47 AM, Sébastien Brisard wrote: >> Hi Gilles, >> >>> As you both point out indirectly, the Javadoc system is not exactly suitable >>> to compose a scientific document. But I remind that its main goal is to >>> explain the API of a code, not to explain the science that supports the >>> implementation. >>> >> As a matter of fact, I was talking about the user's guide, not the >> Javadoc. But you have a good point on this too, below! >> >>> Of course, we can provide some additional hints about the scientific >>> background, but I do not think that we should go too far in that direction >>> within the Javadoc. Attempting to write complex stuff (e.g. equations) using >>> either HTML tables or ASCII art (or any script that amounts to making it >>> impossible to read the equations directly within the source) would render >>> the comments useless within the source, forcing the developer to read the >>> formatted doc if he actually needs that information. >>> It will also make it a two-step process to check whether the doc is in >>> agreement with the code. [A second step that will easily be "forgotten".] >>> >>> If people are interested to provide more in-depth usage and background info, >>> I suggest that we do it only in the user guide. >>> My opinion is that such a document should be written in LaTeX (thus made >>> "universally" available as a PDF file) with all the formatting freedom that >>> comes with it. >>> >>> Tutorials should be limited to illustrating selected parts of the library >>> without using fancy formatting tools. [It's not that I don't like those >>> tools, but I do not think that CM has the resources to maintain the complex >>> documents that the API documentation is going to become.] >>> >> So, I guess you mean the online User's guide should essentially be a >> tutorial, while reference material should be provided in a LaTeX file? >> I think you have a very good point with maintenance, sorry I have >> overlooked that... >> >> In you opinion, would you think that reference values (in ulps) for >> the accuracy of special functions should be provided online in the >> website, or as a separate document ? >> I would favor the online website. If I feel the need for mathematical >> formulas, then this part could go in a separate LaTeX file. >> What do you think? > > Let me ask a naive question: is it possible to embed (and easily > maintain) hyperlinks in LaTex? I suspect the answer is yes, but I > have never done it personally. I would prefer to keep the User > Guide as one document / set of hyperlinked documents and have it > function more or less as it does now - explain enough of the > mathematical background so people understand what the APIs mean and > enough code samples so they can quickly figure out how to use them. > The first goal overlaps with the javadoc; but in the User Guide a > more expository approach can be taken. When combined with examples > this is helpful. > It is theoretically possible. But you would need to embed a link to the commons-math website. It would be possible, but fairly fragile, to have the links point to a local install of the commons-math project. As for your view on what our doc should/should not be. I think I agree. I'd like to say it has never been my wish to write a mathematical treatise (which I would be unable to anyway!). However, besides usage info, I'd like to provide some details on the reliability of the proposed implementations. For the special package, I'm thinking about providing relative error (in ulps) in specific ranges of the argument. It would come down to a few tables, and possibly some graphs. Nothing fancy, but I think this is really info some users might appreciate (I personally am looking for this information). As for mathematical formulas, they would be very limited, in my view. > > We seem to have three options: > > 0) Just keep chugging along with the clunky xdoc and its limitations > 1) Use MathJax to basically embed TeX formulas > 2) Commit TeX sources and just generate and host pdfs > > I am not sure the hosting issue is that big a deal on 1), or the > performance or lack of online access; but I agree these are > negatives. If we can get links to work (especially links to the > javadoc), I would be open to 2). The problem there is the monstrous > task of translating everything and also the requirement that > everyone contributing to the guide be happy with TeX. Most likely > the second item is a net positive for most [math] people vis a vis > xdoc ;) > I am a big fan and long time user of LaTeX. However, I am opposed to option 2 as unrealistic. That would have a huge maintenance cost, as there are no such thing as "good coding practices" in LaTeX. Also, I have experienced writing papers with two-three colleagues, it quickly leads to horrendous code, everyone writing its own (more or less overlapping) macros, and so on. I don't even want to imagine that
Re: [Math] About "NullArgumentException"
Hello, 2012/9/17 Gilles Sadowski : > On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote: >> OK, I give up. Lets do option 2. Just warn users in the User Guide >> somewhere that our APIs are in general not null-safe and unless the >> javadoc explicitly allows nulls, they can expect NPE when passing nulls. > > Thanks, Phil; we are making progress, and I hope that you'll be convinced of > that at some point. > > Another decision still needs to be made. > > I think that everybody now agrees that wherever an argument will be directly > used (i.e. "dereferenced") inside the body of the method[1], it is safe to > not check for null (since the JVM will throw an NPE). > > But, whenever an argument is passed for _later_ use (e.g. stored by a > constructor or passed to another method), we also all expressed that it is > better to fail early if the object is supposed to be non-null. In those > cases, checks are not mandatory (since the JVM will throw NPE at some > point), but we must agree on how optional checks are to be implemented. > 1. The current state of affairs was to throw "NullArgumentException"; in 4.0 >this exception will become a subclass of NPE and we can continue to use >it in the same way as now (i.e. possibly providing additional localizable >error messages). > 2. The alternative is to directly throw a standard NPE, but without any >message, since it wouldn't be localizable with the support of CM's >"context". > > So, which of those alternatives do people want to settle on? > > > Regards, > Gilles > > [1] As opposed to being passed on to another method. > I have another question: are we going to little by little remove all null checks that we feel are not absolutely necessary? I would not mind going through this cleaning phase while working on MATH-854. Best regards, Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[math] apachecon
Hi, does anybody plan to go to ApacheCon 2012? Would be nice to meet each other there. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] apachecon
I should be there. I will present a talk about community gathering around open-source project in the space field… Luc Thomas Neidhart a écrit : >Hi, > >does anybody plan to go to ApacheCon 2012? >Would be nice to meet each other there. > >Thomas > >- >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >For additional commands, e-mail: dev-h...@commons.apache.org -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
Re: [Math] About "NullArgumentException"
On 9/18/12 12:02 PM, Sébastien Brisard wrote: > Hello, > > 2012/9/17 Gilles Sadowski : >> On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote: >>> OK, I give up. Lets do option 2. Just warn users in the User Guide >>> somewhere that our APIs are in general not null-safe and unless the >>> javadoc explicitly allows nulls, they can expect NPE when passing nulls. >> Thanks, Phil; we are making progress, and I hope that you'll be convinced of >> that at some point. >> >> Another decision still needs to be made. >> >> I think that everybody now agrees that wherever an argument will be directly >> used (i.e. "dereferenced") inside the body of the method[1], it is safe to >> not check for null (since the JVM will throw an NPE). >> >> But, whenever an argument is passed for _later_ use (e.g. stored by a >> constructor or passed to another method), we also all expressed that it is >> better to fail early if the object is supposed to be non-null. In those >> cases, checks are not mandatory (since the JVM will throw NPE at some >> point), but we must agree on how optional checks are to be implemented. >> 1. The current state of affairs was to throw "NullArgumentException"; in 4.0 >>this exception will become a subclass of NPE and we can continue to use >>it in the same way as now (i.e. possibly providing additional localizable >>error messages). >> 2. The alternative is to directly throw a standard NPE, but without any >>message, since it wouldn't be localizable with the support of CM's >>"context". >> >> So, which of those alternatives do people want to settle on? >> >> >> Regards, >> Gilles >> >> [1] As opposed to being passed on to another method. >> > I have another question: are we going to little by little remove all > null checks that we feel are not absolutely necessary? I would not > mind going through this cleaning phase while working on MATH-854. I think we should wait to remove the existing null checks until 4.0. This is a significant behavior change, especially for the ones that have been in place and documented since 1.x. Removing the checks and allowing NPEs to propagate will break apps that catch IAE. 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 additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] xdoc vs. apt
Hello. > Hi Phil, > thanks for your thoughts! > > 2012/9/18 Phil Steitz : > > On 9/18/12 6:47 AM, Sébastien Brisard wrote: > >> Hi Gilles, > >> > >>> As you both point out indirectly, the Javadoc system is not exactly > >>> suitable > >>> to compose a scientific document. But I remind that its main goal is to > >>> explain the API of a code, not to explain the science that supports the > >>> implementation. > >>> > >> As a matter of fact, I was talking about the user's guide, not the > >> Javadoc. But you have a good point on this too, below! > >> > >>> Of course, we can provide some additional hints about the scientific > >>> background, but I do not think that we should go too far in that direction > >>> within the Javadoc. Attempting to write complex stuff (e.g. equations) > >>> using > >>> either HTML tables or ASCII art (or any script that amounts to making it > >>> impossible to read the equations directly within the source) would render > >>> the comments useless within the source, forcing the developer to read the > >>> formatted doc if he actually needs that information. > >>> It will also make it a two-step process to check whether the doc is in > >>> agreement with the code. [A second step that will easily be "forgotten".] > >>> > >>> If people are interested to provide more in-depth usage and background > >>> info, > >>> I suggest that we do it only in the user guide. > >>> My opinion is that such a document should be written in LaTeX (thus made > >>> "universally" available as a PDF file) with all the formatting freedom > >>> that > >>> comes with it. > >>> > >>> Tutorials should be limited to illustrating selected parts of the library > >>> without using fancy formatting tools. [It's not that I don't like those > >>> tools, but I do not think that CM has the resources to maintain the > >>> complex > >>> documents that the API documentation is going to become.] > >>> > >> So, I guess you mean the online User's guide should essentially be a > >> tutorial, while reference material should be provided in a LaTeX file? > >> I think you have a very good point with maintenance, sorry I have > >> overlooked that... > >> > >> In you opinion, would you think that reference values (in ulps) for > >> the accuracy of special functions should be provided online in the > >> website, or as a separate document ? > >> I would favor the online website. If I feel the need for mathematical > >> formulas, then this part could go in a separate LaTeX file. > >> What do you think? > > > > Let me ask a naive question: is it possible to embed (and easily > > maintain) hyperlinks in LaTex? I suspect the answer is yes, but I > > have never done it personally. I would prefer to keep the User > > Guide as one document / set of hyperlinked documents and have it > > function more or less as it does now - explain enough of the > > mathematical background so people understand what the APIs mean and > > enough code samples so they can quickly figure out how to use them. > > The first goal overlaps with the javadoc; but in the User Guide a > > more expository approach can be taken. When combined with examples > > this is helpful. > > > It is theoretically possible. But you would need to embed a link to > the commons-math website. It would be possible, but fairly fragile, to > have the links point to a local install of the commons-math project. > > As for your view on what our doc should/should not be. I think I > agree. I'd like to say it has never been my wish to write a > mathematical treatise (which I would be unable to anyway!). However, > besides usage info, I'd like to provide some details on the > reliability of the proposed implementations. For the special package, > I'm thinking about providing relative error (in ulps) in specific > ranges of the argument. It would come down to a few tables, and > possibly some graphs. Nothing fancy, but I think this is really info > some users might appreciate (I personally am looking for this > information). > > As for mathematical formulas, they would be very limited, in my view. I would certainly not want to prevent you from providing this information. If you think that xdoc is more convenient than LaTeX for what you have in mind then it's fine. [I guess that it's possible to embed graphics in xdoc (?).] > > > > We seem to have three options: > > > > 0) Just keep chugging along with the clunky xdoc and its limitations > > 1) Use MathJax to basically embed TeX formulas > > 2) Commit TeX sources and just generate and host pdfs > > > > I am not sure the hosting issue is that big a deal on 1), or the > > performance or lack of online access; but I agree these are > > negatives. If we can get links to work (especially links to the > > javadoc), I would be open to 2). The problem there is the monstrous > > task of translating everything and also the requirement that > > everyone contributing to the guide be happy with TeX. Most likely > > the second item is a net positive
Re: [math] apachecon
On Tue, 18 Sep 2012, Thomas Neidhart wrote: does anybody plan to go to ApacheCon 2012? I'm not involved in math, only validator, but I'll be there :) The Monday (5th November) is a hackathon, which should be a great chance for commons developers (and others!) to get together to work on code / documentation / bugs / ideas. Hopefully quite a few people from the commons community will be able to make it! Nick - 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 83 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: 9 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-19092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-19092012.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 Aban
[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 83 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-19092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-19092012.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: [functor] Patch for FUNCTOR-14, new Generators and Ranges
Hi all,
me again bringing a new implementation idea for the Generators API
in [functor], and looking forward to some thoughts on this :-)
There is a separate branch for this issue [1], and here's what has been done.
- Split Generator interface into Generator interface and LoopGenerator
(abstract class). IMO, this will help in modularization (see this discussion
[2])
in the Generators API, as the stop() method and the wrapped generators,
for instance, had been added because of the generators created for handling
execution flow control (e.g.: GenerateWhile, UntilGenerate, etc).
- Moved LoopGenerator and its implementations under the newly created
org.apache.commons.functor.generator.loop package.
- Moved IntegerRange and LongRange from
org.apache.commons.functor.generator.util to
the newly created org.apache.commons.functor.generator.range package.
- Created a Range API, with a Range interface, a Ranges helper interface and
some implementations (including existing IntegerRange and LongRange, and new
ones like DoubleRange, FloatRange and CharacterRange).
- Added steps different than 1 to Ranges (not the generator interface, as this
is related only to ranges).
- The Ranges implemented are all Generators too, what is very convenient, as
you
can use Ranges to both define intervals and/or execute a procedure for each of
its
elements.
I've wrote a sample code using the existing Generators API [3] and wrote the
same code for the new Generators API [4]. The API is compatible, but as some
packages changed, you have to update existing code (but as [functor] hasn't
been
released yet, it shouldn't be a problem I believe :-). Both codes produce the
same output too (0 1 2 3 4 5 6 7 8 9 ).
And here's an example [5] of creating Ranges and using them as Generators. More
examples can be found in the tests for the Generator and the Range API's.
I've updated the examples page and added tests. I've also updated the parent
pom to 26, but as this is not related to the FUNCTOR-14 issue, we can drop this
part when merging the code.
I'll merge the changes to trunk if everybody thinks this new implementation is
better than the current one.
A side note: PHP recently got generators too [6], and an interesting thing that
I noticed in
their Wiki was the discussion about callback functions. After reading the
discussion, for me it looks like [functor] generators API is more similar to
callback handler. Differently than the Python and PHP implementations with the
yield statement.
Thank you in advance!
[1]
https://svn.apache.org/repos/asf/commons/proper/functor/branches/generators-FUNCTOR-14
[2] http://markmail.org/message/nymsk7l64aj4csxi
[3] https://gist.github.com/3747204
[4] https://gist.github.com/3747207
[5] https://gist.github.com/3747224
[5] https://wiki.php.net/rfc/generators
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com
>
> From: Matt Benson
>To: Bruno P. Kinoshita
>Cc: Commons Developers List
>Sent: Wednesday, 6 June 2012 9:56 AM
>Subject: Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges
>
>On Tue, Jun 5, 2012 at 11:48 PM, Bruno P. Kinoshita
> wrote:
>> Hi Matt,
>>
>>
>>> Would there be a type of Range that could not be turned into a
>>> Generator given a compatible Step parameter? If not, we could define:
>>>
>>> interface Range {
>>> ...
>>> Generator toGenerator(S step);
>>> }
>>>
>>> This way, Range itself does not contain a step, but still maintains
>>> control over how a step is used to create a generator.
>>
>> I can't think of any type that could not be turned into a generator given
>> the step parameter. But if a range has no step, I think we would have to
>> remove the isEmpty(), contains(), containsAll() methods from range
>> implementations, as using steps higher than 1, we need to use the step value
>> to check if a range is empty or contains a certain element (e.g.: integer
>> range (1, 2], step 3, check if contains(2) or isEmpty()).
>>
>
>My thought was that by decoupling a Range from a step, you use only
>the bound types/values to determine inclusion of a given value. If a
>Generator is created from (1, 2] with step 3, then that Generator will
>only return 1, but that doesn't reflect on the Range, IMO.
>
>Matt
>
>>
>>> Either way, I like the notion that a Range is its own type that just
>>> *happens* to either provide access to, or an implementation of,
>>> Generator.
>>
>> +1, let it provide access or be an implementation of Generator. In case we
>> do the latter case, I believe isEmpty(), contains() and other methods using
>> the step value would be doable.
>>
>> Regards,
>>
>>
>> Bruno P. Kinoshita
>> http://www.kinoshita.eti.br
>> http://www.tupilabs.com
>>
>> On 06/05/2012 11:52 PM, Matt Benson wrote:
>>>
>>> Hi, Bruno. Likewise, answers inline:
>>>
>>> On Tue, Jun 5, 2012 at 9:32 PM, Bruno P. Kinoshita
>>> wrote:
Hi Matt!
Thanks for your response! Answers adde
Re: [math] apachecon
On 9/18/12 12:29 PM, Thomas Neidhart wrote: > Hi, > > does anybody plan to go to ApacheCon 2012? > Would be nice to meet each other there. > > Thomas > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > I would love to be there, but can't make the hop across the pond this time. I think CFP is about to open for Feb, 2013 in Portland, though, and I would be game to prepare a [math] talk if it fits in the program. Phil - 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 88 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: 1 min 1 sec
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: 1348026870194
[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.an
Re: Promote vfs-cifs out of sandbox?
I turns out the current vfs-smb sandbox already have tests, all we need is to provide it with a test url ( via system property) per vfs test instruction There are 2 fail tests relate to classloader cases which I am not familiar with Can some one take a look? Thanks -D On Mon, Sep 17, 2012 at 3:02 PM, Dan Tran wrote: > I dont know if there is any read only public server. > > Can you just roll in cifs provider into the trunk for 2.1? I will be > your first beta customer ( even thou we are already perform intensive > test in house ) > > -D > > On Mon, Sep 17, 2012 at 1:54 PM, Gary Gregory wrote: >> I could see releasing 2.1 ASAP which is on my to-do list. fixing We could >> then roll out a 2.1.1 or 2.2 with this code in it. But there still would >> need to be some kind of testing. Is there a public server that could be >> used for at least read-only tests? >> >> Gary >> >> On Mon, Sep 17, 2012 at 4:50 PM, Dan Tran wrote: >> >>> perhaps, we can release smb provider as is at commons-vfs and mark it >>> as experimental? I see a number of apache project doing that. >>> >>> -D >>> >>> On Sat, Sep 15, 2012 at 11:36 PM, Dan Tran wrote: >>> > Hello all, >>> > >>> > I took a closer look at writing unit test case for vfs-cifs and came >>> > to a conclusion that the test cases are tough to develop since there >>> > is no available embedded cifs server available ( note that the current >>> > test cases for other provider heavily depends on embedded server like >>> > ftp, sftp, webdav, etc ). And mocking the testcase up is not that >>> > worth. >>> > >>> > So I would like to propose to release cifs provider as a beta together >>> > with vfs-maven-plugin and have users to test it out. My company is >>> > using intensively in house and about the bring it to full production ( >>> > there fore I need to release vfs-maven-plugin at MOJO's codehaus soon >>> > ) >>> > >>> > Any objection for me release it as propose using the same java package >>> > name( org.apache.commons.vfs ) at codehaus? >>> > >>> > Thanks >>> > >>> > -D >>> > >>> > Note I do have test case for cift using provided example pom >>> > >>> > >>> > >>> > >>> > >>> > -- Forwarded message -- >>> > From: Gary Gregory >>> > Date: Mon, Jul 23, 2012 at 4:49 AM >>> > Subject: Re: Promote vfs-cift out of sandbox? >>> > To: Commons Developers List >>> > >>> > >>> > On Mon, Jul 23, 2012 at 3:13 AM, Dan Tran wrote: >>> > >>> >> I have from now to Octorber to either: >>> >> >>> >> 1. Implement test requirement to graduate vfs-cifs out of sandbox at >>> >> Apache common >>> >> >>> >> 2. Release it as a alpha/beta at Codehaus together with >>> vfs-maven-plugin >>> >> >>> >> 3. Release to our internal repo. >>> >> >>> >> The prefer one is 1 >>> >> >>> > >>> > So do I :) >>> > >>> > >>> >> >>> >> What is VFS 2.1 schedule? >>> >> >>> > >>> > I would like to push out a 2.1 sooner rather than later. I still see some >>> > internal clean ups I'd like to do. So it might be out in a month or two. >>> Or >>> > not, it depends on my schedule, priorities and feedback I get once I >>> start >>> > cutting release candidates. >>> > >>> > It's possible that by October, VFS will be on 2.2, 2.3 or greater. >>> > >>> > Gary >>> > >>> > >>> >> Thanks >>> >> >>> >> -Dan >>> >> >>> >> >>> >> On Sun, Jul 22, 2012 at 11:01 PM, Gary Gregory >>> >> wrote: >>> >> > Dan? What are your plans or intentions here? >>> >> > >>> >> > Thank you, >>> >> > Gary >>> >> > >>> >> > On Sat, Jul 21, 2012 at 12:48 AM, Gary Gregory < >>> garydgreg...@gmail.com >>> >> >wrote: >>> >> > >>> >> >> On Jul 19, 2012, at 12:11, Ralph Goers >>> >> wrote: >>> >> >> >>> >> >> > >>> >> >> > On Jul 18, 2012, at 10:38 AM, sebb wrote: >>> >> >> > >>> >> >> > >>> >> >> > Can the above be read as follows for VFS and JCIFS: you cannot >>> >> copy >>> >> >> the >>> >> >> > JCIFS jar into VFS (which we do not) but the VFS POM can point >>> to >>> >> it >>> >> >> (which >>> >> >> > we do). >>> >> >> >>> >> >> The above document is only proposed, not actual policy. >>> >> >> >>> >> >> The following is the resolved list of questions: >>> >> >> >>> >> >> http://www.apache.org/legal/resolved.html >>> >> >> >>> >> >> In particular: >>> >> >> >>> >> >> http://www.apache.org/legal/resolved.html#optional >>> >> >> >>> >> >> "Will the majority of users want to use my product without >>> adding >>> >> the >>> >> >> optional components? >>> >> >> >>> >>> >> >> >>> I do not see how this helps. It's yes or no: Can the VFS POM >>> point >>> >> to >>> >> >> >>> a set of artifacts that are LGPL? >>> >> >> >> >>> >> >> >> Whether the answer is yes or no depends on the answer to the above >>> >> >> question. >>> >> >> > >>> >> >> > There are only a few file systems in VFS that should be considered >>> >> >> required. All the ones that require the user to include a third-party >>> >> jar - >>> >> >> even if it is Jackrabbit's - are op
Re: Promote vfs-cifs out of sandbox?
Tests in error: testLoadClass(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests): code.ClassToLoad testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests): code.sealed.AnotherClass Tests run: 1745, Failures: 0, Errors: 2, Skipped: 0 On Tue, Sep 18, 2012 at 9:49 PM, Dan Tran wrote: > I turns out the current vfs-smb sandbox already have tests, all we > need is to provide it with a test url ( via system property) per vfs > test instruction > > There are 2 fail tests relate to classloader cases which I am not familiar > with > > Can some one take a look? > > Thanks > > -D > > On Mon, Sep 17, 2012 at 3:02 PM, Dan Tran wrote: >> I dont know if there is any read only public server. >> >> Can you just roll in cifs provider into the trunk for 2.1? I will be >> your first beta customer ( even thou we are already perform intensive >> test in house ) >> >> -D >> >> On Mon, Sep 17, 2012 at 1:54 PM, Gary Gregory wrote: >>> I could see releasing 2.1 ASAP which is on my to-do list. fixing We could >>> then roll out a 2.1.1 or 2.2 with this code in it. But there still would >>> need to be some kind of testing. Is there a public server that could be >>> used for at least read-only tests? >>> >>> Gary >>> >>> On Mon, Sep 17, 2012 at 4:50 PM, Dan Tran wrote: >>> perhaps, we can release smb provider as is at commons-vfs and mark it as experimental? I see a number of apache project doing that. -D On Sat, Sep 15, 2012 at 11:36 PM, Dan Tran wrote: > Hello all, > > I took a closer look at writing unit test case for vfs-cifs and came > to a conclusion that the test cases are tough to develop since there > is no available embedded cifs server available ( note that the current > test cases for other provider heavily depends on embedded server like > ftp, sftp, webdav, etc ). And mocking the testcase up is not that > worth. > > So I would like to propose to release cifs provider as a beta together > with vfs-maven-plugin and have users to test it out. My company is > using intensively in house and about the bring it to full production ( > there fore I need to release vfs-maven-plugin at MOJO's codehaus soon > ) > > Any objection for me release it as propose using the same java package > name( org.apache.commons.vfs ) at codehaus? > > Thanks > > -D > > Note I do have test case for cift using provided example pom > > > > > > -- Forwarded message -- > From: Gary Gregory > Date: Mon, Jul 23, 2012 at 4:49 AM > Subject: Re: Promote vfs-cift out of sandbox? > To: Commons Developers List > > > On Mon, Jul 23, 2012 at 3:13 AM, Dan Tran wrote: > >> I have from now to Octorber to either: >> >> 1. Implement test requirement to graduate vfs-cifs out of sandbox at >> Apache common >> >> 2. Release it as a alpha/beta at Codehaus together with vfs-maven-plugin >> >> 3. Release to our internal repo. >> >> The prefer one is 1 >> > > So do I :) > > >> >> What is VFS 2.1 schedule? >> > > I would like to push out a 2.1 sooner rather than later. I still see some > internal clean ups I'd like to do. So it might be out in a month or two. Or > not, it depends on my schedule, priorities and feedback I get once I start > cutting release candidates. > > It's possible that by October, VFS will be on 2.2, 2.3 or greater. > > Gary > > >> Thanks >> >> -Dan >> >> >> On Sun, Jul 22, 2012 at 11:01 PM, Gary Gregory >> wrote: >> > Dan? What are your plans or intentions here? >> > >> > Thank you, >> > Gary >> > >> > On Sat, Jul 21, 2012 at 12:48 AM, Gary Gregory < garydgreg...@gmail.com >> >wrote: >> > >> >> On Jul 19, 2012, at 12:11, Ralph Goers >> wrote: >> >> >> >> > >> >> > On Jul 18, 2012, at 10:38 AM, sebb wrote: >> >> > >> >> > >> >> > Can the above be read as follows for VFS and JCIFS: you cannot >> copy >> >> the >> >> > JCIFS jar into VFS (which we do not) but the VFS POM can point to >> it >> >> (which >> >> > we do). >> >> >> >> The above document is only proposed, not actual policy. >> >> >> >> The following is the resolved list of questions: >> >> >> >> http://www.apache.org/legal/resolved.html >> >> >> >> In particular: >> >> >> >> http://www.apache.org/legal/resolved.html#optional >> >> >> >> "Will the majority of users want to use my product without adding >> the >> >> optional components? >> >> >>> >> >> >>> I
[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 105 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: 1 min 9 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: 1 minute 7 seconds [INFO] Finished at: Wed Sep 19 05:07:13 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/common
[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 88 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.012 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 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.061 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.055 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.035 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 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.016 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.349 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.024 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: 15 seconds [INFO] Finished at: Wed Sep 19 05:42:48 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 83 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: 14 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: 1348033704542
[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]
