Re: [math] Binary or text resource files?

[Gilles Sadowski]

Hello.

> testing of special functions involves comparing actual values returned
> by CM with expected values as computed with an arbitrary precision
> software (I use Maxima [1] for this purpose). As I intend these tests
> to be assesments of the overall accuracy of our implementations, the
> number of test values is quite large.

How large?

> For the time being, I've inlined
> the reference values in double[][] arrays, in the test classes.

A priori, that's fine.

> This
> clutters the code, and I will move these reference values to resource
> files.

I'm not fond of this idea.
I prefer unit test classes to be self-contained as much as possible.

> In order to limit the size of these files, I'm considering binary
> files, the obvious drawback being the lack of readability (for those
> of us who haven't entered the Matrix yet).
> So what I would propose to add a readme.txt file in the same resource
> file directory, where the content of each binary file would be
> detailed.
> Would you object to that?

Why do you want to test a very large number of values? Isn't it enough to
select problematic cases (near boundaries, very small values, very large
values, etc.).

I'm not sure that unit tests should aim at testing all values exhaustively.
That might be a side project, maybe to be included in the user guide (?).

> I'm thinking of reserving the *.dat extension to these binary files.
> This would entail renaming a few resource files from *.dat (I had
> myself introduced in the optimization.general package) to *.txt. Is
> that OK?

Let's first decide about the break-up...


Regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Re: Single root for Exceptions

[Gilles Sadowski]

On Wed, Aug 29, 2012 at 06:33:05PM -0700, Phil Steitz wrote:
> On 8/29/12 3:04 PM, Gilles Sadowski wrote:
> > Hello.
> >
> > To summarize:
> >  (1) Does anyone disagree with having all CM exceptions inherit
> >  from a new "MathRuntimeException" which itself will inherit
> >  from the standard "RuntimeException"?
> +0
> >  (2) Does anyone disagree with all exceptions being mandatorily
> >  advertized in the "throws" clause of methods and constructors?
> >  That means that for each exception explicitly instantiated in the
> >  body of the method, the instantiated type must appear in "throws"
> >  clause.
> +1 - though I am OK advertising superclasses in cases where that is
> appropriate (but not to the point of (3) below)
> >  (3) Does anyone disagree that the "throws" clause of a method could
> >  advertize "MathRuntimeException" for any exception not thrown by
> >  itself but by a method which it calls?
> >  That means that it is not mandatory to indicate the specific type
> >  for exceptions not explicitly instantiated in the body the current
> >  method.
> -1
> In general, we should avoid that, because it is equivalent to
> "throws Exception." The exceptions that a method in the public
> [math] API propagates should be documented and advertised by it. 
> Which exceptions a method itself generates is an implementation
> artifact.  What is important in the API is what exceptions the
> caller is going to see.  

You are right. As I said, I was not sure that would be a good rule.
[Also I don't think that there are many cases where exceptions are propagated
from lower levels without being advertized in relation to the current
context.]

Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
clauses of all CM methods?
Does someone absolutely needs this task tobe completed before releasing 3.1?
[I don't think that it's possible without a huge effort from everyone.]


Regards,
Gilles

> 
> Phil
> >
> >
> > I'm not sure about point (3); it seems that it would avoid duplicating
> > descriptions of lower-level preconditions for CM methods that calls other CM
> > methods or advertizing something that would be an implementation detail for
> > the calling method. I didn't check how often that would apply...
> > At first sight, that would surely avoid that upper levels are tightly
> > coupled to lower levels: if a method is modified to throw a new exception,
> > methods that call it do not have to update their documentation and "throws"
> > clause.
> >
> >
> > Regards,
> > Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Binary or text resource files?

[Sébastien Brisard]

Hi Gilles,
thanks for your answer.

2012/8/30 Gilles Sadowski :
> Hello.
>
>> testing of special functions involves comparing actual values returned
>> by CM with expected values as computed with an arbitrary precision
>> software (I use Maxima [1] for this purpose). As I intend these tests
>> to be assesments of the overall accuracy of our implementations, the
>> number of test values is quite large.
>
> How large?
>
>> For the time being, I've inlined
>> the reference values in double[][] arrays, in the test classes.
>
> A priori, that's fine.
>
>> This
>> clutters the code, and I will move these reference values to resource
>> files.
>
> I'm not fond of this idea.
> I prefer unit test classes to be self-contained as much as possible.
>
>> In order to limit the size of these files, I'm considering binary
>> files, the obvious drawback being the lack of readability (for those
>> of us who haven't entered the Matrix yet).
>> So what I would propose to add a readme.txt file in the same resource
>> file directory, where the content of each binary file would be
>> detailed.
>> Would you object to that?
>
> Why do you want to test a very large number of values? Isn't it enough to
> select problematic cases (near boundaries, very small values, very large
> values, etc.).
>
That would make sense if we follow the path you sketch below.
To be the devil's advocate: there is one minor objection, though:
depending on the implementation, problematic values are not always the
same. But that is tractable (we incrementally add problematic values
as new implementations are written, never removing any of the values
previously considered as problematic).

> I'm not sure that unit tests should aim at testing all values exhaustively.
> That might be a side project, maybe to be included in the user guide (?).
>
I like this idea very much. In fact I would like to be able to provide
the user with a full report on accuracy, for specific ranges of the
argument (if relevant). Doing so in the user guide would give us the
opportunity to include graphs, which might help. The only objection I
would have is the following: surefire reports are generated
automatically, so that the impact on accuracy of any change in the
implementation gets reported immediately.

Maybe we could have a side project which gets automatically run as
part of the build cycle, and which produces human readable reports. I
like practical experience in this field, so II would welcome any
suggestion.

Sébastien


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Re: Single root for Exceptions

[Sébastien Brisard]

Hi,

2012/8/30 Gilles Sadowski :
> On Wed, Aug 29, 2012 at 06:33:05PM -0700, Phil Steitz wrote:
>> On 8/29/12 3:04 PM, Gilles Sadowski wrote:
>> > Hello.
>> >
>> > To summarize:
>> >  (1) Does anyone disagree with having all CM exceptions inherit
>> >  from a new "MathRuntimeException" which itself will inherit
>> >  from the standard "RuntimeException"?
>> +0
>> >  (2) Does anyone disagree with all exceptions being mandatorily
>> >  advertized in the "throws" clause of methods and constructors?
>> >  That means that for each exception explicitly instantiated in the
>> >  body of the method, the instantiated type must appear in "throws"
>> >  clause.
>> +1 - though I am OK advertising superclasses in cases where that is
>> appropriate (but not to the point of (3) below)
>> >  (3) Does anyone disagree that the "throws" clause of a method could
>> >  advertize "MathRuntimeException" for any exception not thrown by
>> >  itself but by a method which it calls?
>> >  That means that it is not mandatory to indicate the specific type
>> >  for exceptions not explicitly instantiated in the body the current
>> >  method.
>> -1
>> In general, we should avoid that, because it is equivalent to
>> "throws Exception." The exceptions that a method in the public
>> [math] API propagates should be documented and advertised by it.
>> Which exceptions a method itself generates is an implementation
>> artifact.  What is important in the API is what exceptions the
>> caller is going to see.
>
> You are right. As I said, I was not sure that would be a good rule.
> [Also I don't think that there are many cases where exceptions are propagated
> from lower levels without being advertized in relation to the current
> context.]
>
> Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
> clauses of all CM methods?
> Does someone absolutely needs this task tobe completed before releasing 3.1?
> [I don't think that it's possible without a huge effort from everyone.]
>

No hurry on my side, but I'm happy contributing. In order not to tread
on anyone's feet, maybe each of us should be assigned one package (for
a start).
S

>
> Regards,
> Gilles
>
>>
>> Phil
>> >
>> >
>> > I'm not sure about point (3); it seems that it would avoid duplicating
>> > descriptions of lower-level preconditions for CM methods that calls other 
>> > CM
>> > methods or advertizing something that would be an implementation detail for
>> > the calling method. I didn't check how often that would apply...
>> > At first sight, that would surely avoid that upper levels are tightly
>> > coupled to lower levels: if a method is modified to throw a new exception,
>> > methods that call it do not have to update their documentation and "throws"
>> > clause.
>> >
>> >
>> > Regards,
>> > Gilles
>
> -
> 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: [math] Re: Single root for Exceptions

[Luc Maisonobe]

Le 30/08/2012 05:08, Sébastien Brisard a écrit :
> Hello,
> 
> 2012/8/30 Gilles Sadowski :
>> Hello.
>>
>> To summarize:
>>  (1) Does anyone disagree with having all CM exceptions inherit
>>  from a new "MathRuntimeException" which itself will inherit
>>  from the standard "RuntimeException"?
> +0: my background is not good enough.

+1

>>  (2) Does anyone disagree with all exceptions being mandatorily
>>  advertized in the "throws" clause of methods and constructors?
>>  That means that for each exception explicitly instantiated in the
>>  body of the method, the instantiated type must appear in "throws"
>>  clause.

+1
> +1, if only for the sake of the so-called "Luc's trick" (@Luc:
> something's called your name, that's the beginning of celebrity ;)

-1 to it being named Luc's trick :-(

> !!!).
>>  (3) Does anyone disagree that the "throws" clause of a method could
>>  advertize "MathRuntimeException" for any exception not thrown by
>>  itself but by a method which it calls?
>>  That means that it is not mandatory to indicate the specific type
>>  for exceptions not explicitly instantiated in the body the current
>>  method.
>>
>>
>> I'm not sure about point (3); it seems that it would avoid duplicating
>> descriptions of lower-level preconditions for CM methods that calls other CM
>> methods or advertizing something that would be an implementation detail for
>> the calling method. I didn't check how often that would apply...
>> At first sight, that would surely avoid that upper levels are tightly
>> coupled to lower levels: if a method is modified to throw a new exception,
>> methods that call it do not have to update their documentation and "throws"
>> clause.
>>
> -0: I don't like the idea of advertising such a general exception, but
> again, I lack the general background in computer science. Maybe we
> could ask ourselves two questions
> 1. If, when changing the implementation of a method, it turns out that
> an exception is no longer thrown, or a new one is thrown, does this
> break compatibility?
> 2. Surely, there are two cases about exceptions thrown by a method
> called within the method under consideration.
>   2a. If the exception is raised by a method called by an object the
> end-user knows, e.g
> 
> public ReturnType theMethod(final ParamType x) {
> // I am going to throw an exception
> theOtherMethod(x);
> }
> 
> in this case, the exception might still be meaningful to the end user
> 
>   2b. if the exception is raised by a method called with an object the
> end-user doesn't know
> 
> public ReturnType theMethod(final ParamType x) {
> 
> final AnotherType y = ...
> // I am going to throw an exception
> theOtherMethod(y);
> }
> 
> in this case, the exception might not be so meaningful, and maybe
> advertising MRE would be sufficient (although I still do not really
> like that).
> 
> Cases 2a and 2b might well be not so clear cut. E. g. what do we do
> with method calls like theOtherMethod(x, y)? So I would be slightly in
> favor of precisely advertizing every single exception.

I think we must advertise them, as long as they are thrown by [maht]
itself. Either we do the work all the way through or we don't do it.
Stopping at the first level of public API would be wasting our time
without benefits. Exceptions do propagate, if we need to know they are
thrown, we need it all the way through. If we decide its too much work,
then we should not bother doing it even on first call level.

Luc

> 
> These are just a few thoughts from someone which is not experienced in
> this field...
> 
> 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: [codec] Vacuous bit mask operation on integer value in UnixCrypt

[Gary Gregory]

Hi Christian,
(pardon the brevity, on the phone)
I do not have the privilege to grant access. There is a whole process
for that. Yes, create JIRAs for patches. Don't know why git does that,
sorry.

Gary

On Aug 29, 2012, at 20:00, Christian Hammers  wrote:

> Hello
>
> I did some more unit tests. Could you grant me commit rights (Apache
> user "chammers") or should I fill your inbox with patches? :-)
>
> BTW, I would have made a git fork but the "$Id$" lines show up in
> every diff. Why are they not expanded in the git shadow repo? I thought
> that would happen at the svn commit time?
>
> bye,
>
> -christian-
>
> Am Wed, 29 Aug 2012 09:05:56 -0400
> schrieb Gary Gregory :
>
>> How about this:
>>
>> 1. Let's get the digest package to 100% code coverage (or as closed
>> to it as possible)
>> 2. Clean up the code (removing the "vacuous" code)
>>
>> Also to do is fix the remaining check styles.
>>
>> Patches welcome!
>>
>> Gary
>>
>> On Tue, Aug 28, 2012 at 2:47 AM, Thomas Neidhart
>> wrote:
>>
>>> On 08/28/2012 03:33 AM, Christian Hammers wrote:
 Am Tue, 28 Aug 2012 00:09:41 +0200
 schrieb Christian Hammers :

> Hello
>
> Am Mon, 27 Aug 2012 16:39:23 -0400
> schrieb Gary Gregory :
>
>> On Mon, Aug 27, 2012 at 2:53 PM, Thomas Neidhart
>> wrote:
>>
>>> On 08/27/2012 03:36 PM, Gary Gregory wrote:
 Hi All:

 FindBugs says the following a couple of times for UnixCrypt:
 "Vacuous bit mask operation on integer value
 (INT_VACUOUS_BIT_OPERATION)

 This is an integer bit operation (and, or, or exclusive or)
 that doesn't
>>> do
 any useful work (e.g., v & 0x)."
 This makes me wonder if the whole class is correct in the
 first place and if/how/why these ops got in there.

 Was this translated (incorrectly) from JetSpeed's
 implementation? Where
>>> the
 types (int vs longs?) in JetSpeed different? Where did
 JetSpeed get this implementation?
>>>
>>> I do not know the source of the JetSpeed implementation, but
>>> there are several (slightly different) variants of this
>>> floating around in other projects:
>>>
>>>
>>>
>>> http://grepcode.com/file/repository.jboss.org/maven2/postgresql/postgresql/8.4-701.jdbc3/org/postgresql/util/UnixCrypt.java
>>>
>>>
>>>
>>> http://grepcode.com/file/repo1.maven.org/maven2/org.mortbay.jetty/jetty/6.1.11/org/mortbay/jetty/security/UnixCrypt.jav
>>>
>>> The jetty version looks the most clean one, and as it is also
>>> Apache license, maybe we should take this one and cleanup the
>>> code a bit?
>>>
>>
>> The first thing to try would be to drop in the Jetty impl (I
>> looked at the one in the 8.1 version) and see our unit tests
>> run unchanged (aside from the different APIs). I cannot do this
>> today though. Feel try to try ;)
>>
>> Gary
>
> The original Jetspeed source also had this "v & 0x":
>
>>> http://www.javadocexamples.com/java_source/org/apache/jetspeed/services/security/ldap/UnixCrypt.java.html
>
>>> http://archive.apache.org/dist/jakarta/jetspeed/jetspeed-current-src.zip
>
> But I will have a look now how the Jetty source looks in
> comparison...

 The Aki Yoshida version from Jetty does not pass the UTF-8 unit
 tests: It gives the same result for ASCII inputs and also for a
 single 0x80 but two consecutive bytes > 0x80 like 0xC3 0xA4 for
 "ä" gives a different result than "perl -e 'print crypt("ä",
 "xx");'. As it looks totally different than all the other
 UnixCrypt implementations I have no clue how to fix it.

 Regarding the other ones, most of them have a common ancestors in
 John Dumas Java port which is the one with the "v & 0x".
 http://www.dynamic.net.au/christos/crypt/ gives a nice
 genealogy overview :)

 The first one mentioned there, from Davit Scott, also works but is
 not only significantly slower than all the other ones but also
 does not have a clear license statement so I doubt that we could
 use it.

 Our current version, which is similar to the PostgreSQL JDBC one
 mentioned above, passes all tests without the "0x" though.
 As it "int" is defined as a 4 bytes in the JLS 4.2.1 and not
 platform dependend like in C, we could just remove it and make
 FindBugs happy.

 Apropos, "Math.abs(r.nextInt()) % numSaltChars" could be replaced
 by "r.nextInt(numSaltChars)" and FindBugs would be completely
 clean for this file.
>>>
>>> Interesting is also that in the postgresql variant, the bitwise and
>>> operation is using a slightly different argument:
>>>
>>> c &= 0x0fff;
>>>
>>> So they must have made this observation too because the rest of the
>>> code looks very much the same.
>>>
>>> Thomas
>>>
>>> -

Re: [math] Re: Single root for Exceptions

[Gilles Sadowski]

> > [...]
> >
> > Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
> > clauses of all CM methods?
> > Does someone absolutely needs this task tobe completed before releasing 3.1?
> > [I don't think that it's possible without a huge effort from everyone.]

Ticket created:
  https://issues.apache.org/jira/browse/MATH-854

> >
> 
> No hurry on my side, but I'm happy contributing. In order not to tread
> on anyone's feet, maybe each of us should be assigned one package (for
> a start).

Good idea.

Gilles: packages "o.a.c.m.optimization"
 "o.a.c.m.analysis.function"
 "o.a.c.m.analysis.solvers"
 "o.a.c.m.analysis.integration"
 "o.a.c.m.analysis.interpolation"


Best regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[all] maven-changes-plugin failed to parse JIRA XML.

[Gary Gregory]

I've started to see this SAXParseException in [codec] trunk and other
commons components. Ideas?

[INFO] Generating "JIRA Report" report--- maven-changes-plugin:2.7.1
Aug 30, 2012 9:16:52 AM org.apache.commons.httpclient.HttpMethodBase
getResponseBody
WARNING: Going to buffer response body of large or unknown size. Using
getResponseBodyAsStream instead is recommended.
[INFO] Downloading from JIRA at:
http://issues.apache.org/jira/secure/IssueNavigator.jspa?view=rss&pid=12310464&statusIds=5
ype=2&type=3&type=4&type=5&type=6&sorter/field=fixVersions&sorter/order=DESC&sorter/field=issuetype&sorter/order=ASC&sorter
pMax=100&reset=true&decorator=none
[WARNING]
org.apache.maven.plugin.MojoExecutionException: Failed to parse JIRA XML.
at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:132)
at org.apache.maven.plugin.jira.JiraXML.parseXML(JiraXML.java:108)
at
org.apache.maven.plugin.jira.AbstractJiraDownloader.getIssueList(AbstractJiraDownloader.java:755)
at
org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:347)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.xml.sax.SAXParseException: The entity name must immediately
follow the '&' in the entity reference.
at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown
Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown
Source)
at org.apache.xerces.impl.XMLScanner.scanAttributeValue(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanAttribute(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
Source)
at org

Re: [all] maven-changes-plugin failed to parse JIRA XML.

[sebb]

On 30 August 2012 14:20, Gary Gregory  wrote:
> I've started to see this SAXParseException in [codec] trunk and other
> commons components. Ideas?

JIRA was upgraded recently, perhaps the plugin is not very resilient
to XML formatting changes.

Does the problem still occur with components that have not been
updated to CP 26?

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [site] yet another proposal on how to restyle the commons site

[Luc Maisonobe]

Le 30/08/2012 15:52, Simone Tripodi a écrit :
> Hi all guys,
> 
> new Apache Maven Fluido Skin is gonna be released soon, I started
> experimenting locally how the _main_ commons site would look alike if
> the new skin would be applied (with some modifications): voilà[1] :)
> 
> If you think that putting more effort on it would worth, I am glad to
> continue doing more work on applying also to a component site (with
> different layout), publish to my local ASF space, and see the result -
> OTOH I'll become definitively silent and won't bother on that topic
> anymore :)
> 
> WDYT?

These are good news. Would we be able with this setting to go to svnpubsub?

Luc

> Many thanks in advance, all the best!
> -Simo
> 
> [1] http://people.apache.org/~simonetripodi/commons/index.html
> 
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.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: [site] yet another proposal on how to restyle the commons site

[Christian Grobmeier]

On Thu, Aug 30, 2012 at 4:13 PM, Luc Maisonobe  wrote:
> Le 30/08/2012 15:52, Simone Tripodi a écrit :
>> Hi all guys,
>>
>> new Apache Maven Fluido Skin is gonna be released soon, I started
>> experimenting locally how the _main_ commons site would look alike if
>> the new skin would be applied (with some modifications): voilà[1] :)
>>
>> If you think that putting more effort on it would worth, I am glad to
>> continue doing more work on applying also to a component site (with
>> different layout), publish to my local ASF space, and see the result -
>> OTOH I'll become definitively silent and won't bother on that topic
>> anymore :)
>>
>> WDYT?
>
> These are good news. Would we be able with this setting to go to svnpubsub?

If we would implement it the way like we did in Logging, then yes.
Basically we would then generate the site locally, copy the html to
another svn repository and commit it. We would be independent of the
build system.

Cheers
Christian


> Luc
>
>> Many thanks in advance, all the best!
>> -Simo
>>
>> [1] http://people.apache.org/~simonetripodi/commons/index.html
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.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
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [site] yet another proposal on how to restyle the commons site

[Simone Tripodi]

Salut Luc,

> These are good news. Would we be able with this setting to go to svnpubsub?

yes they will work, skin and SCM publishing are unrelated stuff -
Olivier Lamy, which is also commons committer, already did the job for
Apache DirectMemory via a new mvn plugin called scm-publish, hopefully
we can provide us a guideline.

I will invite him to publicly explain us how to manage the SvnPubSub.

Thanks!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [site] yet another proposal on how to restyle the commons site

[Gary Gregory]

Well done Simo!

I have a couple of issues though:

- The main page should, like today, give you a table of the active (aka
proper) components.
- I find the slider gadget thingy disconcerting. I do not know that it will
slide, I thought it was a bug and that the other components were missing
(see above). Then, poof!, it does slide. I would not use it so prominently
if at all.
- Does not look good on my iPhone. The main issue is that the top menu bar
takes up a third of the screen. We need to consider mobile IMO.

Thank you and keep up the good work!

Gary

On Thu, Aug 30, 2012 at 9:52 AM, Simone Tripodi wrote:

> Hi all guys,
>
> new Apache Maven Fluido Skin is gonna be released soon, I started
> experimenting locally how the _main_ commons site would look alike if
> the new skin would be applied (with some modifications): voilà[1] :)
>
> If you think that putting more effort on it would worth, I am glad to
> continue doing more work on applying also to a component site (with
> different layout), publish to my local ASF space, and see the result -
> OTOH I'll become definitively silent and won't bother on that topic
> anymore :)
>
> WDYT?
> Many thanks in advance, all the best!
> -Simo
>
> [1] http://people.apache.org/~simonetripodi/commons/index.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [site] yet another proposal on how to restyle the commons site

[Benedikt Ritter]

Hi Simo,

great work, I really like the fluido skin and would like to see it go
live for commons.

One minor issue: does the releases section need to have a drop down
although there is only one entry in the sub menu? IMHO the commons
parent site does not need a releases section at all. The list
displayed is the same as the one from the components sub section.
OTOH it would be cool if the releases page displayed the last recently
released components sorted by date with a link to their release notes.
But I guess that would imply a lot of maintenance work.

Regards,
Benedikt


2012/8/30 Simone Tripodi :
> Hi all guys,
>
> new Apache Maven Fluido Skin is gonna be released soon, I started
> experimenting locally how the _main_ commons site would look alike if
> the new skin would be applied (with some modifications): voilà[1] :)
>
> If you think that putting more effort on it would worth, I am glad to
> continue doing more work on applying also to a component site (with
> different layout), publish to my local ASF space, and see the result -
> OTOH I'll become definitively silent and won't bother on that topic
> anymore :)
>
> WDYT?
> Many thanks in advance, all the best!
> -Simo
>
> [1] http://people.apache.org/~simonetripodi/commons/index.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.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: [site] yet another proposal on how to restyle the commons site

[Gary Gregory]

On Thu, Aug 30, 2012 at 10:50 AM, Benedikt Ritter wrote:

> Hi Simo,
>
> great work, I really like the fluido skin and would like to see it go
> live for commons.
>
> One minor issue: does the releases section need to have a drop down
> although there is only one entry in the sub menu? IMHO the commons
> parent site does not need a releases section at all. The list
> displayed is the same as the one from the components sub section.
> OTOH it would be cool if the releases page displayed the last recently
> released components sorted by date with a link to their release notes.
> But I guess that would imply a lot of maintenance work.
>

Unless there is a way to pick up the latest posts from announce@...

Gary

>
> Regards,
> Benedikt
>
>
> 2012/8/30 Simone Tripodi :
> > Hi all guys,
> >
> > new Apache Maven Fluido Skin is gonna be released soon, I started
> > experimenting locally how the _main_ commons site would look alike if
> > the new skin would be applied (with some modifications): voilà[1] :)
> >
> > If you think that putting more effort on it would worth, I am glad to
> > continue doing more work on applying also to a component site (with
> > different layout), publish to my local ASF space, and see the result -
> > OTOH I'll become definitively silent and won't bother on that topic
> > anymore :)
> >
> > WDYT?
> > Many thanks in advance, all the best!
> > -Simo
> >
> > [1] http://people.apache.org/~simonetripodi/commons/index.html
> >
> > http://people.apache.org/~simonetripodi/
> > http://simonetripodi.livejournal.com/
> > http://twitter.com/simonetripodi
> > http://www.99soft.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
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [math] Re: Single root for Exceptions

[Phil Steitz]

On Aug 30, 2012, at 4:56 AM, Gilles Sadowski  
wrote:

>>> [...]
>>> 
>>> Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
>>> clauses of all CM methods?
>>> Does someone absolutely needs this task tobe completed before releasing 3.1?
>>> [I don't think that it's possible without a huge effort from everyone.]
> 
> Ticket created:
>  https://issues.apache.org/jira/browse/MATH-854
> 
>>> 
>> 
>> No hurry on my side, but I'm happy contributing. In order not to tread
>> on anyone's feet, maybe each of us should be assigned one package (for
>> a start).
> 
> Good idea.
> 
> Gilles: packages "o.a.c.m.optimization"
> "o.a.c.m.analysis.function"
> "o.a.c.m.analysis.solvers"
> "o.a.c.m.analysis.integration"
> "o.a.c.m.analysis.interpolation"

+1 to divide and conquer.  I will start on stat.

Phil
> 
> 
> Best regards,
> Gilles
> 
> -
> 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] maven-changes-plugin failed to parse JIRA XML.

[Gary Gregory]

On Thu, Aug 30, 2012 at 10:58 AM, sebb  wrote:

> On 30 August 2012 15:28, Gary Gregory  wrote:
> > On Thu, Aug 30, 2012 at 9:37 AM, sebb  wrote:
> >
> >> On 30 August 2012 14:20, Gary Gregory  wrote:
> >> > I've started to see this SAXParseException in [codec] trunk and other
> >> > commons components. Ideas?
> >>
> >> JIRA was upgraded recently, perhaps the plugin is not very resilient
> >> to XML formatting changes.
> >>
> >> Does the problem still occur with components that have not been
> >> updated to CP 26?
> >>
> >
> > It does not happen on BCEL which is on CP 25.
>
> What happens if you change BCEL to use CP 26?
>

It works (I committed it).

Gary


>
> > Gary
> >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> > Spring Batch in Action: http://bit.ly/bqpbCK
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [site] yet another proposal on how to restyle the commons site

[Benedikt Ritter]

2012/8/30 Gary Gregory :
> On Thu, Aug 30, 2012 at 10:50 AM, Benedikt Ritter wrote:
>
>> Hi Simo,
>>
>> great work, I really like the fluido skin and would like to see it go
>> live for commons.
>>
>> One minor issue: does the releases section need to have a drop down
>> although there is only one entry in the sub menu? IMHO the commons
>> parent site does not need a releases section at all. The list
>> displayed is the same as the one from the components sub section.
>> OTOH it would be cool if the releases page displayed the last recently
>> released components sorted by date with a link to their release notes.
>> But I guess that would imply a lot of maintenance work.
>>
>
> Unless there is a way to pick up the latest posts from announce@...

That would be even cooler ;-)

>
> Gary
>
>>
>> Regards,
>> Benedikt
>>
>>
>> 2012/8/30 Simone Tripodi :
>> > Hi all guys,
>> >
>> > new Apache Maven Fluido Skin is gonna be released soon, I started
>> > experimenting locally how the _main_ commons site would look alike if
>> > the new skin would be applied (with some modifications): voilà[1] :)
>> >
>> > If you think that putting more effort on it would worth, I am glad to
>> > continue doing more work on applying also to a component site (with
>> > different layout), publish to my local ASF space, and see the result -
>> > OTOH I'll become definitively silent and won't bother on that topic
>> > anymore :)
>> >
>> > WDYT?
>> > Many thanks in advance, all the best!
>> > -Simo
>> >
>> > [1] http://people.apache.org/~simonetripodi/commons/index.html
>> >
>> > http://people.apache.org/~simonetripodi/
>> > http://simonetripodi.livejournal.com/
>> > http://twitter.com/simonetripodi
>> > http://www.99soft.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
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [site] yet another proposal on how to restyle the commons site

[sebb]

On 30 August 2012 15:34, Gary Gregory  wrote:
> Well done Simo!
>
> I have a couple of issues though:
>
> - The main page should, like today, give you a table of the active (aka
> proper) components.
> - I find the slider gadget thingy disconcerting. I do not know that it will
> slide, I thought it was a bug and that the other components were missing
> (see above). Then, poof!, it does slide. I would not use it so prominently
> if at all.
> - Does not look good on my iPhone. The main issue is that the top menu bar
> takes up a third of the screen. We need to consider mobile IMO.

Agreed.

Also, the current event looks wrong in the page footer. Not sure it
makes sense for the built-by Maven logo to be there either.

There's no Apache or Apache Commons logo, presumably because these use
relative links, and the images are missing.
Could you add the directory so we can see what it would look like?

The drop-down heading "External Links" should be renamed to "Apache
Links", or possibly flattened into direct links.

The top menu bar extends across the whole page, but the body does not.
This causes problems on mobile devices.

I agree it's difficult to read body text that extends across the whole
page, but there is now a lot of space either side that could be used
perhaps for logos or other items.

> Thank you and keep up the good work!
>
> Gary
>
> On Thu, Aug 30, 2012 at 9:52 AM, Simone Tripodi 
> wrote:
>
>> Hi all guys,
>>
>> new Apache Maven Fluido Skin is gonna be released soon, I started
>> experimenting locally how the _main_ commons site would look alike if
>> the new skin would be applied (with some modifications): voilà[1] :)
>>
>> If you think that putting more effort on it would worth, I am glad to
>> continue doing more work on applying also to a component site (with
>> different layout), publish to my local ASF space, and see the result -
>> OTOH I'll become definitively silent and won't bother on that topic
>> anymore :)
>>
>> WDYT?
>> Many thanks in advance, all the best!
>> -Simo
>>
>> [1] http://people.apache.org/~simonetripodi/commons/index.html
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] maven-changes-plugin failed to parse JIRA XML.

[sebb]

On 30 August 2012 16:04, Gary Gregory  wrote:
> On Thu, Aug 30, 2012 at 10:58 AM, sebb  wrote:
>
>> On 30 August 2012 15:28, Gary Gregory  wrote:
>> > On Thu, Aug 30, 2012 at 9:37 AM, sebb  wrote:
>> >
>> >> On 30 August 2012 14:20, Gary Gregory  wrote:
>> >> > I've started to see this SAXParseException in [codec] trunk and other
>> >> > commons components. Ideas?
>> >>
>> >> JIRA was upgraded recently, perhaps the plugin is not very resilient
>> >> to XML formatting changes.
>> >>
>> >> Does the problem still occur with components that have not been
>> >> updated to CP 26?
>> >>
>> >
>> > It does not happen on BCEL which is on CP 25.
>>
>> What happens if you change BCEL to use CP 26?
>>
>
> It works (I committed it).

What about codec on CP 25?

Try to establish whether it is CP, JIRA or component related.

> Gary
>
>
>>
>> > Gary
>> >
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> > Spring Batch in Action: http://bit.ly/bqpbCK
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] MD5 impls

[Gary Gregory]

On Thu, Aug 30, 2012 at 11:53 AM, sebb  wrote:

> On 30 August 2012 16:51, Gary Gregory  wrote:
> > On Thu, Aug 30, 2012 at 11:41 AM, sebb  wrote:
> >
> >> On 30 August 2012 16:01, Gary Gregory  wrote:
> >> > All,
> >> >
> >> > Do we want both the MD5 in org.apache.commons.codec.digest.Md5Crypt
> and
> >> the
> >> > one accessed through org.apache.commons.codec.digest.DigestUtils?
> >> >
> >> > Thouhgts?
> >>
> >> Are they the same implementation?
> >>
> >
> > Well, no, org.apache.commons.codec.digest.Md5Crypt is new in trunk, it
> has
> > not been in a release yet.
>
> So why has it been added if there was already an implementation?
>

'twas an oversight.

Gary


>
> > Gary
> >
> >
> >> Dropping one would break compatibility, but one could potentially be
> >> deprecated, and in the meantime invoke the other.
> >>
> >> > Thank you,
> >> > Gary
> >> >
> >> > --
> >> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> >> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> >> > Spring Batch in Action: http://bit.ly/bqpbCK
> >> > Blog: http://garygregory.wordpress.com
> >> > Home: http://garygregory.com/
> >> > Tweet! http://twitter.com/GaryGregory
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> > Spring Batch in Action: http://bit.ly/bqpbCK
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: svn commit: r1378996 - in /commons/proper/codec/trunk/src: main/java/org/apache/commons/codec/ main/java/org/apache/commons/codec/language/ test/java/org/apache/commons/codec/ test/java/org/apache

[sebb AT ASF]

On 30 August 2012 16:50,   wrote:
> Author: sebb
> Date: Thu Aug 30 15:50:01 2012
> New Revision: 1378996
>
> URL: http://svn.apache.org/viewvc?rev=1378996&view=rev
> Log:
> Add SVN EOL setting

Might fix the Checkstyle trailing EOL complaints?

> Modified:
> 
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java
>(contents, props changed)
> 
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/language/Nysiis.java
>(props changed)
> 
> commons/proper/codec/trunk/src/test/java/org/apache/commons/codec/CharsetsTest.java
>(contents, props changed)
> 
> commons/proper/codec/trunk/src/test/java/org/apache/commons/codec/language/NysiisTest.java
>(props changed)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1378996 - in /commons/proper/codec/trunk/src: main/java/org/apache/commons/codec/ main/java/org/apache/commons/codec/language/ test/java/org/apache/commons/codec/ test/java/org/apache

[Gary Gregory]

On Thu, Aug 30, 2012 at 12:36 PM, sebb AT ASF  wrote:

> On 30 August 2012 16:50,   wrote:
> > Author: sebb
> > Date: Thu Aug 30 15:50:01 2012
> > New Revision: 1378996
> >
> > URL: http://svn.apache.org/viewvc?rev=1378996&view=rev
> > Log:
> > Add SVN EOL setting
>
> Might fix the Checkstyle trailing EOL complaints?
>

Yes!

Thank you,
Gary


>
> > Modified:
> >
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java
>   (contents, props changed)
> >
> commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/language/Nysiis.java
>   (props changed)
> >
> commons/proper/codec/trunk/src/test/java/org/apache/commons/codec/CharsetsTest.java
>   (contents, props changed)
> >
> commons/proper/codec/trunk/src/test/java/org/apache/commons/codec/language/NysiisTest.java
>   (props changed)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [codec] MD5 impls

[Thomas Neidhart]

On 08/30/2012 06:31 PM, Gary Gregory wrote:
> On Thu, Aug 30, 2012 at 11:53 AM, sebb  wrote:
> 
>> On 30 August 2012 16:51, Gary Gregory  wrote:
>>> On Thu, Aug 30, 2012 at 11:41 AM, sebb  wrote:
>>>
 On 30 August 2012 16:01, Gary Gregory  wrote:
> All,
>
> Do we want both the MD5 in org.apache.commons.codec.digest.Md5Crypt
>> and
 the
> one accessed through org.apache.commons.codec.digest.DigestUtils?
>
> Thouhgts?

 Are they the same implementation?

>>>
>>> Well, no, org.apache.commons.codec.digest.Md5Crypt is new in trunk, it
>> has
>>> not been in a release yet.
>>
>> So why has it been added if there was already an implementation?
>>
> 
> 'twas an oversight.

it is not the same.

MD5Crypt uses the MD5 MessageDigest algorithm to produce a crypt variant
based on it.

We could replace the call in MD5Crypt

   MessageDigest ctx = MessageDigest.getInstance(MD5_ALGORITHM);

with

   MessageDigest ctx = DigestUtils.getMd5Digest();

but then we would have to update the exception to be thrown
(NoSuchAlgorithmException vs. RuntimeException)

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Re: Single root for Exceptions

[Thomas Neidhart]

On 08/30/2012 12:41 PM, Luc Maisonobe wrote:
> Le 30/08/2012 05:08, Sébastien Brisard a écrit :
>> Hello,

Hi,

sorry, I did not participate much in the discussion.

>> 2012/8/30 Gilles Sadowski :
>>> Hello.
>>>
>>> To summarize:
>>>  (1) Does anyone disagree with having all CM exceptions inherit
>>>  from a new "MathRuntimeException" which itself will inherit
>>>  from the standard "RuntimeException"?
>> +0: my background is not good enough.
> 
> +1

+0

>>>  (2) Does anyone disagree with all exceptions being mandatorily
>>>  advertized in the "throws" clause of methods and constructors?
>>>  That means that for each exception explicitly instantiated in the
>>>  body of the method, the instantiated type must appear in "throws"
>>>  clause.
> 
> +1

+1

>>>  (3) Does anyone disagree that the "throws" clause of a method could
>>>  advertize "MathRuntimeException" for any exception not thrown by
>>>  itself but by a method which it calls?
>>>  That means that it is not mandatory to indicate the specific type
>>>  for exceptions not explicitly instantiated in the body the current
>>>  method.
>>>
>>>
>>> I'm not sure about point (3); it seems that it would avoid duplicating
>>> descriptions of lower-level preconditions for CM methods that calls other CM
>>> methods or advertizing something that would be an implementation detail for
>>> the calling method. I didn't check how often that would apply...
>>> At first sight, that would surely avoid that upper levels are tightly
>>> coupled to lower levels: if a method is modified to throw a new exception,
>>> methods that call it do not have to update their documentation and "throws"
>>> clause.
>>>
>> -0: I don't like the idea of advertising such a general exception, but
>> again, I lack the general background in computer science. Maybe we
>> could ask ourselves two questions
>> 1. If, when changing the implementation of a method, it turns out that
>> an exception is no longer thrown, or a new one is thrown, does this
>> break compatibility?
>> 2. Surely, there are two cases about exceptions thrown by a method
>> called within the method under consideration.
>>   2a. If the exception is raised by a method called by an object the
>> end-user knows, e.g
>>
>> public ReturnType theMethod(final ParamType x) {
>> // I am going to throw an exception
>> theOtherMethod(x);
>> }
>>
>> in this case, the exception might still be meaningful to the end user
>>
>>   2b. if the exception is raised by a method called with an object the
>> end-user doesn't know
>>
>> public ReturnType theMethod(final ParamType x) {
>>
>> final AnotherType y = ...
>> // I am going to throw an exception
>> theOtherMethod(y);
>> }
>>
>> in this case, the exception might not be so meaningful, and maybe
>> advertising MRE would be sufficient (although I still do not really
>> like that).
>>
>> Cases 2a and 2b might well be not so clear cut. E. g. what do we do
>> with method calls like theOtherMethod(x, y)? So I would be slightly in
>> favor of precisely advertizing every single exception.
> 
> I think we must advertise them, as long as they are thrown by [maht]
> itself. Either we do the work all the way through or we don't do it.
> Stopping at the first level of public API would be wasting our time
> without benefits. Exceptions do propagate, if we need to know they are
> thrown, we need it all the way through. If we decide its too much work,
> then we should not bother doing it even on first call level.

I agree here with the comment of Luc, either we do it full-way or leave
it as it is now.

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[codec] javadoc style

[Thomas Neidhart]

Hi,

there are quite some differences on the javadoc style in the source
files, e.g. the number of spaces before a @param description, whether
there is an empty line between @param, @return and @throws.

Any thoughts on that? I am willing to clean up but do not want to impose
any personal preference.

btw. how do we treat the cases in the language.bm package wrt System.err
statements? For now I marked them as comment and put a FIXME.
The are there in case an unexpected input is read from a resource file
at runtime.

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Binary or text resource files?

[Ted Dunning]

I, in contrast, am quite fond of this technique if there is a clear
correlation between the test and the resource and if the resource is scoped
to testing.

On Thu, Aug 30, 2012 at 5:44 AM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:

> > This
> > clutters the code, and I will move these reference values to resource
> > files.
>
> I'm not fond of this idea.
> I prefer unit test classes to be self-contained as much as possible.
>

Re: [site] yet another proposal on how to restyle the commons site

[Simone Tripodi]

Hi all!

>> - I find the slider gadget thingy disconcerting. I do not know that it will
>> slide, I thought it was a bug and that the other components were missing
>> (see above). Then, poof!, it does slide. I would not use it so prominently
>> if at all.

table restored, more work on the carousel could improve the l'n'f IMHO
but let's back to the roots first :)

>> - Does not look good on my iPhone. The main issue is that the top menu bar
>> takes up a third of the screen. We need to consider mobile IMO.
>
> Agreed.

unfortunately Twitter Bootstrap just provides a responsive design wich
adapts the "desktop" components to mobile phones - and they announced
in the ML they don't have any plan (yet?) to write  aport on the
mobile.

Fortunately, I can still provide you a sample with the "classic"
sidebar menu navigation - as shown in[1] - which should adapt better
on mobile phones. Can you please verify it?
TIA!

> There's no Apache or Apache Commons logo, presumably because these use
> relative links, and the images are missing.
> Could you add the directory so we can see what it would look like?
>

done!

At that point I'll be working on applying the skin on a component to
see how it looks like to show you, hopefully we will find an agreement
and definitively upgrade the commons site :P

Have a nice day, all the best!
-Simo

[1] http://people.apache.org/~simonetripodi/commons-sidebar/index.html

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [site] yet another proposal on how to restyle the commons site

[Simone Tripodi]

as a side note: I think we could upgrade also the commons logo itself
starting from an svg the ASF made available[1], unfortunately I am not
good with inkscape... :(

best,
-Simo

[1] http://www.apache.org/foundation/press/kit/

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Thu, Aug 30, 2012 at 9:33 PM, Simone Tripodi
 wrote:
> Hi all!
>
>>> - I find the slider gadget thingy disconcerting. I do not know that it will
>>> slide, I thought it was a bug and that the other components were missing
>>> (see above). Then, poof!, it does slide. I would not use it so prominently
>>> if at all.
>
> table restored, more work on the carousel could improve the l'n'f IMHO
> but let's back to the roots first :)
>
>>> - Does not look good on my iPhone. The main issue is that the top menu bar
>>> takes up a third of the screen. We need to consider mobile IMO.
>>
>> Agreed.
>
> unfortunately Twitter Bootstrap just provides a responsive design wich
> adapts the "desktop" components to mobile phones - and they announced
> in the ML they don't have any plan (yet?) to write  aport on the
> mobile.
>
> Fortunately, I can still provide you a sample with the "classic"
> sidebar menu navigation - as shown in[1] - which should adapt better
> on mobile phones. Can you please verify it?
> TIA!
>
>> There's no Apache or Apache Commons logo, presumably because these use
>> relative links, and the images are missing.
>> Could you add the directory so we can see what it would look like?
>>
>
> done!
>
> At that point I'll be working on applying the skin on a component to
> see how it looks like to show you, hopefully we will find an agreement
> and definitively upgrade the commons site :P
>
> Have a nice day, all the best!
> -Simo
>
> [1] http://people.apache.org/~simonetripodi/commons-sidebar/index.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] javadoc style

[Gary Gregory]

On Thu, Aug 30, 2012 at 2:57 PM, Thomas Neidhart
wrote:

> Hi,
>
> there are quite some differences on the javadoc style in the source
> files, e.g. the number of spaces before a @param description, whether
> there is an empty line between @param, @return and @throws.
>

I like the default Eclipse formatting style:

 /**
 * ...
 *
 * @param arg1
 *blah blah blah blah
 * @throws SomeException
 *blah blah
 */


> Any thoughts on that? I am willing to clean up but do not want to impose
> any personal preference.
>

I'm not sure it is worth fixing, but if it bothers you, feel free :)


>
> btw. how do we treat the cases in the language.bm package wrt System.err
> statements? For now I marked them as comment and put a FIXME.
> The are there in case an unexpected input is read from a resource file
> at runtime.
>

I would probably throw an IllegalArgumentException. You can code that and
see if the tests all pass.

Gary


>
> Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [site] yet another proposal on how to restyle the commons site

[Benedikt Ritter]

2012/8/30 Simone Tripodi :
> Hi all!
>
>>> - I find the slider gadget thingy disconcerting. I do not know that it will
>>> slide, I thought it was a bug and that the other components were missing
>>> (see above). Then, poof!, it does slide. I would not use it so prominently
>>> if at all.
>
> table restored, more work on the carousel could improve the l'n'f IMHO
> but let's back to the roots first :)
>
>>> - Does not look good on my iPhone. The main issue is that the top menu bar
>>> takes up a third of the screen. We need to consider mobile IMO.
>>
>> Agreed.
>
> unfortunately Twitter Bootstrap just provides a responsive design wich
> adapts the "desktop" components to mobile phones - and they announced
> in the ML they don't have any plan (yet?) to write  aport on the
> mobile.
>
> Fortunately, I can still provide you a sample with the "classic"
> sidebar menu navigation - as shown in[1] - which should adapt better
> on mobile phones. Can you please verify it?
> TIA!
>

Hi Simo,

I've uploaded a screenshot of that page taken with my mobile [1].
Doesn't look to well, anything you can do about that?

Benedikt

[1] https://dl.dropbox.com/u/3058827/fluido-commons-on-iPhone.PNG

>> There's no Apache or Apache Commons logo, presumably because these use
>> relative links, and the images are missing.
>> Could you add the directory so we can see what it would look like?
>>
>
> done!
>
> At that point I'll be working on applying the skin on a component to
> see how it looks like to show you, hopefully we will find an agreement
> and definitively upgrade the commons site :P
>
> Have a nice day, all the best!
> -Simo
>
> [1] http://people.apache.org/~simonetripodi/commons-sidebar/index.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.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: [site] yet another proposal on how to restyle the commons site

[Gary Gregory]

Step 1: Make "Welcome to the Apache Commons" half its current font size.

G

On Thu, Aug 30, 2012 at 4:24 PM, Benedikt Ritter wrote:

> 2012/8/30 Simone Tripodi :
> > Hi all!
> >
> >>> - I find the slider gadget thingy disconcerting. I do not know that it
> will
> >>> slide, I thought it was a bug and that the other components were
> missing
> >>> (see above). Then, poof!, it does slide. I would not use it so
> prominently
> >>> if at all.
> >
> > table restored, more work on the carousel could improve the l'n'f IMHO
> > but let's back to the roots first :)
> >
> >>> - Does not look good on my iPhone. The main issue is that the top menu
> bar
> >>> takes up a third of the screen. We need to consider mobile IMO.
> >>
> >> Agreed.
> >
> > unfortunately Twitter Bootstrap just provides a responsive design wich
> > adapts the "desktop" components to mobile phones - and they announced
> > in the ML they don't have any plan (yet?) to write  aport on the
> > mobile.
> >
> > Fortunately, I can still provide you a sample with the "classic"
> > sidebar menu navigation - as shown in[1] - which should adapt better
> > on mobile phones. Can you please verify it?
> > TIA!
> >
>
> Hi Simo,
>
> I've uploaded a screenshot of that page taken with my mobile [1].
> Doesn't look to well, anything you can do about that?
>
> Benedikt
>
> [1] https://dl.dropbox.com/u/3058827/fluido-commons-on-iPhone.PNG
>
> >> There's no Apache or Apache Commons logo, presumably because these use
> >> relative links, and the images are missing.
> >> Could you add the directory so we can see what it would look like?
> >>
> >
> > done!
> >
> > At that point I'll be working on applying the skin on a component to
> > see how it looks like to show you, hopefully we will find an agreement
> > and definitively upgrade the commons site :P
> >
> > Have a nice day, all the best!
> > -Simo
> >
> > [1] http://people.apache.org/~simonetripodi/commons-sidebar/index.html
> >
> > http://people.apache.org/~simonetripodi/
> > http://simonetripodi.livejournal.com/
> > http://twitter.com/simonetripodi
> > http://www.99soft.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
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [site] yet another proposal on how to restyle the commons site

[sebb]

On 30 August 2012 20:33, Simone Tripodi  wrote:
> Hi all!
>
>>> - I find the slider gadget thingy disconcerting. I do not know that it will
>>> slide, I thought it was a bug and that the other components were missing
>>> (see above). Then, poof!, it does slide. I would not use it so prominently
>>> if at all.
>
> table restored, more work on the carousel could improve the l'n'f IMHO
> but let's back to the roots first :)
>
>>> - Does not look good on my iPhone. The main issue is that the top menu bar
>>> takes up a third of the screen. We need to consider mobile IMO.
>>
>> Agreed.
>
> unfortunately Twitter Bootstrap just provides a responsive design wich
> adapts the "desktop" components to mobile phones - and they announced
> in the ML they don't have any plan (yet?) to write  aport on the
> mobile.
>
> Fortunately, I can still provide you a sample with the "classic"
> sidebar menu navigation - as shown in[1] - which should adapt better
> on mobile phones. Can you please verify it?

Looks fine on my Android phone using the default browser.
Works well to have sidebar menu because one can shift the page across,
and then scroll the content.

Not so good using Opera Mini, but that is probably an issue with their server.

Also looks much better on my laptop.

> TIA!
>
>> There's no Apache or Apache Commons logo, presumably because these use
>> relative links, and the images are missing.
>> Could you add the directory so we can see what it would look like?
>>
>
> done!
>
> At that point I'll be working on applying the skin on a component to
> see how it looks like to show you, hopefully we will find an agreement
> and definitively upgrade the commons site :P
>
> Have a nice day, all the best!
> -Simo
>
> [1] http://people.apache.org/~simonetripodi/commons-sidebar/index.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.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: [site] yet another proposal on how to restyle the commons site

[Olivier Lamy]

Hi,

2012/8/30 Simone Tripodi :
> Salut Luc,
>
>> These are good news. Would we be able with this setting to go to svnpubsub?
>
> yes they will work, skin and SCM publishing are unrelated stuff -
> Olivier Lamy, which is also commons committer, already did the job for
> Apache DirectMemory via a new mvn plugin called scm-publish, hopefully
> we can provide us a guideline.
>
> I will invite him to publicly explain us how to manage the SvnPubSub.
Yup this plugin works (and you can simply use as today mvn site-deploy
for a single module build :-) )
I tested that for directmemory.a.o and archiva.a.o
Note the archiva is a bit more complicated as it included more than
one reactor but some sub site.
But in the commons case I would recommend something similar we are
testing for maven site
Note this site include a lot of sub site (versionned plugins
documentation, shared components, scm etc...)
But if using the plugin for svnsubpub this means checkout too much
content for just deploying a plugin site.
See
olamy@minotaur:~$ du -sh /www/maven.apache.org
6.3G/www/maven.apache.org
olamy@minotaur:~$ du -sh /www/commons.apache.org
2.3G/www/commons.apache.org

So we are trying a mixed solution :-) (branch:
http://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk/).
The main site is build tru cms (a buildbot job run maven site plugin
and push content then we can publish to live:
http://maventest.apache.org).
The sub sites are deployed using the scmpub sub plugin. To avoid
pubsub to delete those sub parts (because there are not generated via
buildbot job), we worked with infra for configuring subpath to not
delete in a file called expath.txt
(http://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk/content/resources/extpaths.txt)

This plugin is in maven sandbox
(http://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-scm-publish-plugin/).
Quick explanation of how that works:
* checkout (by default) or update of the target svnpub path to a local directory
* list all files from the original and the new deployed site directory
* compare both content
* scm add for new files, scm delete for deleted files
* copy files from deployed site directory to directory with checkout
content (fix possible line ending issues)
* checkin
* et voilà

I'm satisfied by how that works today :-) I will probably release a
first version next week (as I need that for releasing archiva) before
I will test that works with github for gh pages site.

Let me know if you need more details.

>
> Thanks!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] maven-changes-plugin failed to parse JIRA XML.

[Dennis Lundberg]

Hi

You've stumbled upon
http://jira.codehaus.org/browse/MCHANGES-285
due to the recent upgrade of the ASF JIRA instance.

On 2012-08-30 15:20, Gary Gregory wrote:
> I've started to see this SAXParseException in [codec] trunk and other
> commons components. Ideas?
> 
> [INFO] Generating "JIRA Report" report--- maven-changes-plugin:2.7.1
> Aug 30, 2012 9:16:52 AM org.apache.commons.httpclient.HttpMethodBase
> getResponseBody
> WARNING: Going to buffer response body of large or unknown size. Using
> getResponseBodyAsStream instead is recommended.
> [INFO] Downloading from JIRA at:
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?view=rss&pid=12310464&statusIds=5
> ype=2&type=3&type=4&type=5&type=6&sorter/field=fixVersions&sorter/order=DESC&sorter/field=issuetype&sorter/order=ASC&sorter
> pMax=100&reset=true&decorator=none
> [WARNING]
> org.apache.maven.plugin.MojoExecutionException: Failed to parse JIRA XML.
> at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:132)
> at org.apache.maven.plugin.jira.JiraXML.parseXML(JiraXML.java:108)
> at
> org.apache.maven.plugin.jira.AbstractJiraDownloader.getIssueList(AbstractJiraDownloader.java:755)
> at
> org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:347)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.xml.sax.SAXParseException: The entity name must immediately
> follow the '&' in the entity reference.
> at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown
> Source)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown
> Source)
> at org.apache.xerces.impl.XMLScanner.scanAttributeValue(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanAttribute(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at org.apache.xerces.parsers.XML11Co

Re: [site] yet another proposal on how to restyle the commons site

[Olivier Lamy]

2012/8/30 Olivier Lamy :
> Hi,
>
> 2012/8/30 Simone Tripodi :
>> Salut Luc,
>>
>>> These are good news. Would we be able with this setting to go to svnpubsub?
>>
>> yes they will work, skin and SCM publishing are unrelated stuff -
>> Olivier Lamy, which is also commons committer, already did the job for
>> Apache DirectMemory via a new mvn plugin called scm-publish, hopefully
>> we can provide us a guideline.
>>
>> I will invite him to publicly explain us how to manage the SvnPubSub.
> Yup this plugin works (and you can simply use as today mvn site-deploy
> for a single module build :-) )
> I tested that for directmemory.a.o and archiva.a.o
> Note the archiva is a bit more complicated as it included more than
> one reactor but some sub site.
> But in the commons case I would recommend something similar we are
> testing for maven site
> Note this site include a lot of sub site (versionned plugins
> documentation, shared components, scm etc...)
> But if using the plugin for svnsubpub this means checkout too much
> content for just deploying a plugin site.
> See
> olamy@minotaur:~$ du -sh /www/maven.apache.org
> 6.3G/www/maven.apache.org
> olamy@minotaur:~$ du -sh /www/commons.apache.org
> 2.3G/www/commons.apache.org
>
> So we are trying a mixed solution :-) (branch:
> http://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk/).
> The main site is build tru cms (a buildbot job run maven site plugin
> and push content then we can publish to live:
> http://maventest.apache.org).
> The sub sites are deployed using the scmpub sub plugin. To avoid
> pubsub to delete those sub parts (because there are not generated via
> buildbot job), we worked with infra for configuring subpath to not
> delete in a file called expath.txt
> (http://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk/content/resources/extpaths.txt)
>
> This plugin is in maven sandbox
> (http://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-scm-publish-plugin/).
Just moved out of sandbox:
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-scm-publish-plugin/
> Quick explanation of how that works:
> * checkout (by default) or update of the target svnpub path to a local 
> directory
> * list all files from the original and the new deployed site directory
> * compare both content
> * scm add for new files, scm delete for deleted files
> * copy files from deployed site directory to directory with checkout
> content (fix possible line ending issues)
> * checkin
> * et voilà
>
> I'm satisfied by how that works today :-) I will probably release a
> first version next week (as I need that for releasing archiva) before
> I will test that works with github for gh pages site.
>
> Let me know if you need more details.
>
>>
>> Thanks!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Binary or text resource files?

[Phil Steitz]

On 8/29/12 8:22 PM, Sébastien Brisard wrote:
> Hi,
> testing of special functions involves comparing actual values returned
> by CM with expected values as computed with an arbitrary precision
> software (I use Maxima [1] for this purpose). As I intend these tests
> to be assesments of the overall accuracy of our implementations, the
> number of test values is quite large. For the time being, I've inlined
> the reference values in double[][] arrays, in the test classes. This
> clutters the code, and I will move these reference values to resource
> files.
> In order to limit the size of these files, I'm considering binary
> files, the obvious drawback being the lack of readability (for those
> of us who haven't entered the Matrix yet).
> So what I would propose to add a readme.txt file in the same resource
> file directory, where the content of each binary file would be
> detailed.
> Would you object to that?
> I'm thinking of reserving the *.dat extension to these binary files.
> This would entail renaming a few resource files from *.dat (I had
> myself introduced in the optimization.general package) to *.txt. Is
> that OK?

Unless the files are really huge, I think its better to stick with
text files, but as long as you include the readme and keep it up to
date, I would be OK with this.  We have a lot of test files in
src/test/resources for various purposes now.  I like the ones in
/stat because they include documentation about where they came from
/ what they mean in the files themselves. 

Phil
>
> Thanks for your advice,
> 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: [codec] javadoc style

[Christian Hammers]

Am Thu, 30 Aug 2012 16:21:43 -0400
schrieb Gary Gregory :

> On Thu, Aug 30, 2012 at 2:57 PM, Thomas Neidhart
> wrote:
> 
> > Hi,
> >
> > there are quite some differences on the javadoc style in the source
> > files, e.g. the number of spaces before a @param description,
> > whether there is an empty line between @param, @return and @throws.
> >
> 
> I like the default Eclipse formatting style:
> 
>  /**
>  * ...
>  *
>  * @param arg1
>  *blah blah blah blah
>  * @throws SomeException
>  *blah blah
>  */

I usually stick with the default Netbeans formatting style which puts
them on the same line. So does the example in the official Java Code
Conventions (I only refer to it if it does things my way *g*)
Doesn't waste so much precious vertical space either :)

Anyway, what I wanted to ask was if there is maybe some kind of pom.xml
magic that tells Eclipse, Netbeans, IDEA etc how we want the formatting
so that we can all continue pressing ctrl-f for reformat before a commit
and be sure that everything looks proper.


> > btw. how do we treat the cases in the language.bm package wrt
> > System.err statements? For now I marked them as comment and put a
> > FIXME. The are there in case an unexpected input is read from a
> > resource file at runtime.
> >
> 
> I would probably throw an IllegalArgumentException. You can code that
> and see if the tests all pass.

Using commons-logging and log.warn() would also be an options.
More flexible if the use wants those warnings but of course also
unexpected if no stdout is expected by this class. Is there a way
to get Logger instance that is silent if not explicitly turned on? 

bye,

-christian-

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] MD5 impls

[Christian Hammers]

Am Thu, 30 Aug 2012 19:58:54 +0200
schrieb Thomas Neidhart :

> On 08/30/2012 06:31 PM, Gary Gregory wrote:
> > On Thu, Aug 30, 2012 at 11:53 AM, sebb  wrote:
> > 
> >> On 30 August 2012 16:51, Gary Gregory 
> >> wrote:
> >>> On Thu, Aug 30, 2012 at 11:41 AM, sebb  wrote:
> >>>
>  On 30 August 2012 16:01, Gary Gregory 
>  wrote:
> > All,
> >
> > Do we want both the MD5 in
> > org.apache.commons.codec.digest.Md5Crypt
> >> and
>  the
> > one accessed through
> > org.apache.commons.codec.digest.DigestUtils?
> >
> > Thouhgts?
> 
>  Are they the same implementation?
> 
> >>>
> >>> Well, no, org.apache.commons.codec.digest.Md5Crypt is new in
> >>> trunk, it
> >> has
> >>> not been in a release yet.
> >>
> >> So why has it been added if there was already an implementation?
> >>
> > 
> > 'twas an oversight.
> 
> it is not the same.
> 
> MD5Crypt uses the MD5 MessageDigest algorithm to produce a crypt
> variant based on it.
> 
> We could replace the call in MD5Crypt
> 
>MessageDigest ctx = MessageDigest.getInstance(MD5_ALGORITHM);
> 
> with
> 
>MessageDigest ctx = DigestUtils.getMd5Digest();
> 
> but then we would have to update the exception to be thrown
> (NoSuchAlgorithmException vs. RuntimeException)

Same goes for calls to SHA-256 and SHA-512 instances.
But I actually like getting rid of those checked exceptions that
will usually never occur as well as getting rid of the hardcoded
"SHA-512" algorithm name so I switch to DigestUtils.
Patches coming this weekend!

bye,

-christian-
 



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] javadoc style

[Gary Gregory]

On Aug 30, 2012, at 17:58, Christian Hammers  wrote:

> Am Thu, 30 Aug 2012 16:21:43 -0400
> schrieb Gary Gregory :
>
>> On Thu, Aug 30, 2012 at 2:57 PM, Thomas Neidhart
>> wrote:
>>
>>> Hi,
>>>
>>> there are quite some differences on the javadoc style in the source
>>> files, e.g. the number of spaces before a @param description,
>>> whether there is an empty line between @param, @return and @throws.
>>>
>>
>> I like the default Eclipse formatting style:
>>
>> /**
>> * ...
>> *
>> * @param arg1
>> *blah blah blah blah
>> * @throws SomeException
>> *blah blah
>> */
>
> I usually stick with the default Netbeans formatting style which puts
> them on the same line. So does the example in the official Java Code
> Conventions (I only refer to it if it does things my way *g*)
> Doesn't waste so much precious vertical space either :)
>
> Anyway, what I wanted to ask was if there is maybe some kind of pom.xml
> magic that tells Eclipse, Netbeans, IDEA etc how we want the formatting
> so that we can all continue pressing ctrl-f for reformat before a commit
> and be sure that everything looks proper.
>

There is such magic sadly. The best we can do is a combination of
convention and use of the checkstyle maven plugin.

We do not even have a common checkstyle configuration for commons.
Each component does what it wants.

I'd prefer a common guideline but aside from use spaces and not tabs
there is not much shared.

Ideally it would be nice to store in SVN format config for various
IDEs but that gets messy fast with many IDEs and IDE versions.

Gary

>
>>> btw. how do we treat the cases in the language.bm package wrt
>>> System.err statements? For now I marked them as comment and put a
>>> FIXME. The are there in case an unexpected input is read from a
>>> resource file at runtime.
>>>
>>
>> I would probably throw an IllegalArgumentException. You can code that
>> and see if the tests all pass.
>
> Using commons-logging and log.warn() would also be an options.
> More flexible if the use wants those warnings but of course also
> unexpected if no stdout is expected by this class. Is there a way
> to get Logger instance that is silent if not explicitly turned on?
>
> bye,
>
> -christian-
>
> -
> 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: [codec] javadoc style

[Christian Hammers]

Am Thu, 30 Aug 2012 18:05:50 -0400
schrieb Gary Gregory :

> On Aug 30, 2012, at 17:58, Christian Hammers  wrote:
> 
> > Am Thu, 30 Aug 2012 16:21:43 -0400
> > schrieb Gary Gregory :
> >
> >> On Thu, Aug 30, 2012 at 2:57 PM, Thomas Neidhart
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> there are quite some differences on the javadoc style in the
> >>> source files, e.g. the number of spaces before a @param
> >>> description, whether there is an empty line between @param,
> >>> @return and @throws.
> >>>
> >>
> >> I like the default Eclipse formatting style:
> >>
> >> /**
> >> * ...
> >> *
> >> * @param arg1
> >> *blah blah blah blah
> >> * @throws SomeException
> >> *blah blah
> >> */
> >
> > I usually stick with the default Netbeans formatting style which
> > puts them on the same line. So does the example in the official
> > Java Code Conventions (I only refer to it if it does things my way
> > *g*) Doesn't waste so much precious vertical space either :)
> >
> > Anyway, what I wanted to ask was if there is maybe some kind of
> > pom.xml magic that tells Eclipse, Netbeans, IDEA etc how we want
> > the formatting so that we can all continue pressing ctrl-f for
> > reformat before a commit and be sure that everything looks proper.
> >
> 
> There is such magic sadly. The best we can do is a combination of
> convention and use of the checkstyle maven plugin.

Hm, actually there seems to be some possibilities:
For eclipse you can add  to the eclipse plugin:
http://maven.apache.org/plugins/maven-eclipse-plugin/examples/load-code-styles.html
And for netbeans you can ship a nb-configuration.xml which is explicitly
intended to be added to the version control system and be shared.
Example:
http://java.net/projects/electric/sources/svn/content/trunk/electric/electric-3d/nb-configuration.xml?rev=13769

(In the meantime, please be generous if I submit a patch that contains
a newline to much because auto-formatting added it :-))

bye,

-christian-


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] javadoc style

[Gary Gregory]

On Aug 30, 2012, at 18:22, Christian Hammers  wrote:

> Am Thu, 30 Aug 2012 18:05:50 -0400
> schrieb Gary Gregory :
>
>> On Aug 30, 2012, at 17:58, Christian Hammers  wrote:
>>
>>> Am Thu, 30 Aug 2012 16:21:43 -0400
>>> schrieb Gary Gregory :
>>>
 On Thu, Aug 30, 2012 at 2:57 PM, Thomas Neidhart
 wrote:

> Hi,
>
> there are quite some differences on the javadoc style in the
> source files, e.g. the number of spaces before a @param
> description, whether there is an empty line between @param,
> @return and @throws.
>

 I like the default Eclipse formatting style:

/**
* ...
*
* @param arg1
*blah blah blah blah
* @throws SomeException
*blah blah
*/
>>>
>>> I usually stick with the default Netbeans formatting style which
>>> puts them on the same line. So does the example in the official
>>> Java Code Conventions (I only refer to it if it does things my way
>>> *g*) Doesn't waste so much precious vertical space either :)
>>>
>>> Anyway, what I wanted to ask was if there is maybe some kind of
>>> pom.xml magic that tells Eclipse, Netbeans, IDEA etc how we want
>>> the formatting so that we can all continue pressing ctrl-f for
>>> reformat before a commit and be sure that everything looks proper.
>>>
>>
>> There is such magic sadly. The best we can do is a combination of
>> convention and use of the checkstyle maven plugin.
>
> Hm, actually there seems to be some possibilities:
> For eclipse you can add  to the eclipse plugin:
> http://maven.apache.org/plugins/maven-eclipse-plugin/examples/load-code-styles.html
> And for netbeans you can ship a nb-configuration.xml which is explicitly
> intended to be added to the version control system and be shared.
> Example:
> http://java.net/projects/electric/sources/svn/content/trunk/electric/electric-3d/nb-configuration.xml?rev=13769
>
> (In the meantime, please be generous if I submit a patch that contains
> a newline to much because auto-formatting added it :-))

One setting: line length 120.
Gary
>
> bye,
>
> -christian-
>
>
> -
> 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

[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) failed

[Gump]

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 45 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-31082012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-31082012.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

Re: [math] Re: Single root for Exceptions

[Sébastien Brisard]

Hello,

 [...]

 Thus, shall I open a JIRA ticket with the tasks of completing the "throws"
 clauses of all CM methods?
 Does someone absolutely needs this task tobe completed before releasing 
 3.1?
 [I don't think that it's possible without a huge effort from everyone.]
>>
>> Ticket created:
>>  https://issues.apache.org/jira/browse/MATH-854
>>

>>>
>>> No hurry on my side, but I'm happy contributing. In order not to tread
>>> on anyone's feet, maybe each of us should be assigned one package (for
>>> a start).
>>
>> Good idea.
>>
>> Gilles: packages "o.a.c.m.optimization"
>> "o.a.c.m.analysis.function"
>> "o.a.c.m.analysis.solvers"
>> "o.a.c.m.analysis.integration"
>> "o.a.c.m.analysis.interpolation"
>
> +1 to divide and conquer.  I will start on stat.
>
> Phil
>>
>>
>> Best regards,
>> Gilles
>>
I can take care of linear and special, of course!
Sébastien


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-dbcp2 (in module apache-commons) failed

[Gump]

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 45 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: 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/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-31082012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-31082012.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] Binary or text resource files?

[Sébastien Brisard]

Hello,
right, until we reach a consensus, I've inlined the reference data as
double[][], trying to keep those arrays to a reasonable size.
I really would like to provide publicly available extensive validation
of all special functions we have (and will) implement. It seems to me
very important. BOOST does that, which I think lays a standard we
ought to live up to. I'm just not sure what the right way to do this
is. Surely, using unit tests for this is a bit far-fetched. Gilles was
talking about a side-project: did you mean a whole new project in
SANDBOX? That project would then not be a library, but rather a set of
executables which produce nicely formatted reports on the accuracy of
o.a.c.m.special, to be included in the User's guide of CM? Is that
what you had in mind, Gilles? What do others think?

Sébastien


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Binary or text resource files?

[Sébastien Brisard]

2012/8/30 Gilles Sadowski :
> Hello.
>
>> testing of special functions involves comparing actual values returned
>> by CM with expected values as computed with an arbitrary precision
>> software (I use Maxima [1] for this purpose). As I intend these tests
>> to be assesments of the overall accuracy of our implementations, the
>> number of test values is quite large.
>
> How large?
>
For example, testing of GammaDistribution involves some *.csv files,
the largest of which is 300kb. This might not be so huge in the end
(although the svn commit log is quite large!).

BTW, you might notice that I've committed this morning a new *.csv
file. I'm not taking decisions without waiting for everyone's ascent,
I'm merely extending some tests which were already using resource
files. If we decide for another option, I'll change all of this
together.

Best regards,
Sébastien


-
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

[Gump]

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 50 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 2 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: 1346385583649
[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.a

[GUMP@vmgump]: Project commons-chain2 (in module apache-commons) failed

[Gump]

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 67 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: 55 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: 53 seconds
[INFO] Finished at: Fri Aug 31 05:10: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/commons-chain2/atom.

[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

[Gump]

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 50 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: 16 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.007 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.004 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.055 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.103 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 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.033 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.307 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 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.03 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: Fri Aug 31 05:24:45 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

[Gump]

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 45 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: 13 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: 1346390998195
[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] 

[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed

[Gump]

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 50 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: 26 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.202 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.08 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] 

Re: [site] yet another proposal on how to restyle the commons site

[Simone Tripodi]

>> I've uploaded a screenshot of that page taken with my mobile [1].
>> Doesn't look to well, anything you can do about that?

:(

> Step 1: Make "Welcome to the Apache Commons" half its current font size.

yup, I have no more bullets in my gun that the one Gary suggested, I
just re-uploaded the site[1]

How does it look?
TIA,
-Simo

[1] http://people.apache.org/~simonetripodi/commons-sidebar/

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org