Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

2011-12-06 Thread Emmanuel Bourg 

Le 05/12/2011 20:22, Matt Benson a écrit :

I think all that Sebastian is saying is something like "if you can
create your new, cool API and the only things you really miss from
Java 6 are @Override on interface implementation methods and
ServiceLoader, for example, maybe it's worth that tiny bit of extra
pain to reach that slightly larger audience."


+1, this summarize pretty well my opinion. It's not worth requiring Java 
6 if you only use String.isEmpty(). But if you need javax.script that's 
a very good reason to upgrade.


Emmanuel Bourg

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

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

2011-12-06 Thread 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 263 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: 12 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.003 sec
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.provider.TestConstantProvider
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 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.009 sec
Running org.apache.commons.proxy.exception.TestDelegateProviderException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.invoker.TestChainInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.183 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.012 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: 10 seconds
[INFO] Finished at: Wed Dec 07 06:25:21 UTC 2011
[INFO] Final Memory: 24M/58M
[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.

Re: [dbutils] Releasing 1.5

2011-12-06 Thread Henri Yandell 
On Sun, Dec 4, 2011 at 9:28 AM, sebb  wrote:
> On 4 December 2011 17:13, William Speirs  wrote:
>> What is the "rule" on when you can switch Java versions? Is going from
>
> http://commons.apache.org/releases/versioning.html
>
>> 1.4 to 1.5 too small of a version number bump to require a different
>> version of Java? Would we need to wait until 2.0 to switch to Java
>> 1.6?
>
> No, Java version changes don't require a major version bump according
> to Commons rules, though I would perhaps expect one for Java 1.3 to
> 1.6 (say).
>
> I just think that requiring Java 1.6 for a single method may be an
> unnecessary restriction of the field of use.

+1. Generally try to stay 1.5 until a good reason. That good reason
could be a single method, it'd depend on the method :)

Hen

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

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

2011-12-06 Thread 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-jexl-jexl-compat has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 10 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jexl-jexl-compat :  Commons Jexl Package


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-jexl-jexl-compat/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-jexl-compat-*[0-9T].jar] identifier set to 
project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/pom.xml
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-jexl-jexl-compat/gump_work/build_apache-commons_commons-jexl-jexl-compat.html
Work Name: build_apache-commons_commons-jexl-jexl-compat (Type: Build)
Work ended in a state of : Failed
Elapsed: 11 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/gump_mvn_settings.xml
 package 
[Working Directory: /srv/gump/public/workspace/apache-commons/jexl/jexl-compat]
M2_HOME: /opt/maven2
-
symbol  : class Interpreter
location: package org.apache.commons.jexl3
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/Expression.java:[25,60]
 cannot find symbol
symbol  : class Expression
location: package org.apache.commons.jexl3
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/JexlOne.java:[163,18]
 cannot find symbol
symbol  : class Interpreter
location: class org.apache.commons.jexl.JexlOne.JexlOneEngine
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/JexlOne.java:[108,58]
 cannot find symbol
symbol  : class Interpreter
location: class org.apache.commons.jexl.JexlOne
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/JexlOne.java:[183,81]
 no interface expected here
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/JexlOne.java:[100,51]
 cannot find symbol
symbol  : variable EMPTY_CONTEXT
location: class org.apache.commons.jexl.JexlOne.JexlOneEngine
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/JexlOne.java:[122,27]
 jjtAccept(org.apache.commons.jexl3.parser.ParserVisitor,java.lang.Object) in 
org.apache.commons.jexl3.parser.SimpleNode cannot be applied to 
(org.apache.commons.jexl.JexlOne.JexlOneInterpreter,)
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/JexlOne.java:[119,8]
 method does not override or implement a method from a supertype
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/JexlOne.java:[136,8]
 method does not override or implement a method from a supertype
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/JexlOne.java:[142,8]
 method does not override or implement a method from a supertype
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/JexlOne.java:[152,25]
 org.apache.commons.jexl.JexlOne.JexlOneEngine is not abstract and does not 
override abstract method newInstance(java.lang.String,java.lang.Object...) in 
org.apache.commons.jexl3.JexlEngine
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/JexlOne.java:[158,12]
 cannot find symbol
symbol  : method setCache(int)
location: class org.apache.commons.jexl.JexlOne.JexlOneEngine
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/JexlOne.java:[159,12]
 cannot find symbol
symbol  : method setSilent(boolean)
location: class org.apache.commons.jexl.JexlOne.JexlOneEngine
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/JexlOne.java:[170,19]
 incompatible types
found   : org.apache.commons.jexl.JexlOne.JexlOneExpression
required: org.apache.commons.jexl3.JexlScript
/srv/gump/public/workspace/apache-commons/jexl/jexl-compat/src/main/java/org/apache/commons/jexl/JexlOne.java:[168,8]
 method does not override or i

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

2011-12-06 Thread James Carman 
+1, move to jdk6 (go to jdk7 if you want :)
On Dec 5, 2011 9:17 AM, "henrib"  wrote:

> Sorry to bug everyone again, I'm hopelessly trying to make Commons move a
> little forward...
>
> Since a 2-person opposition never breaks the tie, a vote is in order to
> decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123)
> can actually break loose of Java 1.5 compatibility. (sic)
>
> JEXL3 is intended to be a next major release of JEXL that cleans up the
> API,
> making sure the internal/public contract is crystal clear. Since it is a
> major revamp of the API, JEXL3 is intended to be used by new/active
> projects
> that will be deployed on Java6 / Java7. To avoid some development cost,
> I've
> "blatantly" crossed another rule without much thinking by requiring Java6
> for JEXL3 (instead of Java5 which is EOL).
>
> Since JEXL2.1 - aka the next imminent version of jexl2 - already targets
> Java 1.5, I did not think it would start yet another fight with the release
> police. Was I wrong... "Why can't you supporting a EOL-ed platform for a
> new
> version of the project?". (Because it's not a freebie for me but no
> matter).
>
> So, here we are again for some bickering and vote:
> [+1] Yes, you may release the next major release of JEXL3 with a Java6
> requirement
> [-1] No, this is an important case/issue/matter/rule that we continue
> supporting Java 1.5
> [0]  Don't care
>
> Many thanks to those who will vote for their time and patience;
> Henrib
>
> PS: Is there a process to formally move a project from Commons to elsewhere
> within Apache?
>
>
>
>
>
>
>
> --
> View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX

2011-12-06 Thread Gary Gregory 
On Dec 6, 2011, at 15:37, Oliver Heger  wrote:

> Am 05.12.2011 23:02, schrieb Gary Gregory:
>> On Sun, Dec 4, 2011 at 3:24 PM, Oliver Heger
>> wrote:
>>
>>> Am 03.12.2011 22:14, schrieb Gary Gregory:
>>>
 On Sat, Dec 3, 2011 at 3:14 PM, Oliver Heger
 **wrote:

  Am 03.12.2011 17:18, schrieb Gary Gregory:
>
>  On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger
>> wrote:
>>
>>
>>  When building I get a heap space error in testSpeedCheck(org.apache.**
>>
>>> commons.codec.language.bm.**BeiderMorseEncoderTest), even when
>>> setting
>>>
>>>
>>> MAVEN_OPTS=-Xmx1024m. I remember there was discussion about this for
>>> the
>>> last RC. Which amount of memory is required?
>>>
>>>
>>>  Try bumping up your MaxPermSize, for example:
>>
>> MAVEN_OPTS=-XX:MaxPermSize=256m -Xmx1024m
>>
>>
> No luck either. As the error message indicates, the problem really seems
> to be related to heap size (AFAIK you get a specific perm gen error
> message
> otherwise). I get the same error message up to 1400 MB heap space.
> Unfortunately, I cannot increase my heap size beyond this value because I
> reach the limit of my physical memory. For a unit test these seem to be
> tough requirements.
>
>
 If I turn /off/ MAVEN_OPTS (set MAVEN_OPTS=) it still works for me, so
 that's good. I tied the 'mvn test' and 'mvn site'.

 After running site, Maven reports:

 [INFO] Final Memory: 43M/143M

>>>
>>> Did some more testing: the build runs fine for me with Java 1.6, but the
>>> heap space error occurs on Java 1.5 (on Windows 7). Any idea what could be
>>> the source of this problem?
>>>
>>
>> I am good on Java 5 and Windows 7, so I am not sure how to help here.
>>
>> [INFO]
>> 
>> [INFO] BUILD SUCCESS
>> [INFO]
>> 
>> [INFO] Total time: 45.467s
>> [INFO] Finished at: Mon Dec 05 16:59:48 EST 2011
>> [INFO] Final Memory: 15M/65M
>> [INFO]
>> 
>> C:\temp\codec>m3 -version
>> Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
>> Maven home: C:\Java\apache-maven-3.0.3\bin\..
>> Java version: 1.5.0_22, vendor: Sun Microsystems Inc.
>> Java home: C:\Program Files\Java\jdk1.5.0_22\jre
>> Default locale: en_US, platform encoding: Cp1252
>> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>>
>
> Strange. Just for the record, below are my settings. May Java version is 
> slightly older. Maybe a bug in the JDK?

I used maven 3, not 2. Maybe that matters too.

Gary
>
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.5.0_21
> Java home: C:\Program Files\Java\jdk1.5.0_21\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
>
> Oliver
>
>> Gary
>>
>>>
>>> Oliver
>>>
>>>
 Gary



> Oliver
>
>
>  Gary
>>
>>
>>
>>  Otherwise, I did not find major problems. The site has two checkstyle
>>> links: one is clean, the other contains errors.
>>>
>>> Oliver
>>>
>>> Am 03.12.2011 04:06, schrieb Gary Gregory:
>>>
>>>  Good day to you all:
>>>

 I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I
 am
 not calling it RC3 because there are no changes in source files from
 the
 last RC. The only difference is that I built from a fresh checkout of
 the
 RC2 svn tag.

 The changes from RC1 are what Sebb found:
 - EOL in sources
 - Cruft from a dirty build, so I built this RC as I should have the
 first
 time around with:
 - mvn clean
 - mvn deploy -Prelease

 Tag:

 https://svn.apache.org/repos/**asf/commons/proper/codec/
 tags/**
 
>
 commons-codec
 proper/codec/tags/commons-codec
>

>
>  -1.6-RC2

 Site:

 https://people.apache.org/**builds/commons/codec/1.6/RC2/
 <**https://people.apache.org/builds/commons/codec/1.6/RC2/
>>>

[configuration] Java 1.5 compatibility

2011-12-06 Thread Oliver Heger 
As you may have noticed, I was working on the task of making the code 
base ready for Java 1.5 (the tests are still missing). I mainly fixed 
numerous warnings related to raw types and type safety, applied enhanced 
for loops, added annotations, and replaced StringBuffer by StringBuilder.


If somebody finds the time, a review of the changes would be helpful, 
especially in the area where central interfaces have been modified in 
order to incorporate generics.


I tried to preserve binary compatibility, but have not yet run clirr.

Oliver

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

Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX

2011-12-06 Thread Oliver Heger 

Am 05.12.2011 23:02, schrieb Gary Gregory:

On Sun, Dec 4, 2011 at 3:24 PM, Oliver Heger
wrote:


Am 03.12.2011 22:14, schrieb Gary Gregory:


On Sat, Dec 3, 2011 at 3:14 PM, Oliver Heger
**wrote:

  Am 03.12.2011 17:18, schrieb Gary Gregory:


  On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger

wrote:


  When building I get a heap space error in testSpeedCheck(org.apache.**


commons.codec.language.bm.**BeiderMorseEncoderTest), even when
setting


MAVEN_OPTS=-Xmx1024m. I remember there was discussion about this for
the
last RC. Which amount of memory is required?


  Try bumping up your MaxPermSize, for example:


MAVEN_OPTS=-XX:MaxPermSize=256m -Xmx1024m



No luck either. As the error message indicates, the problem really seems
to be related to heap size (AFAIK you get a specific perm gen error
message
otherwise). I get the same error message up to 1400 MB heap space.
Unfortunately, I cannot increase my heap size beyond this value because I
reach the limit of my physical memory. For a unit test these seem to be
tough requirements.



If I turn /off/ MAVEN_OPTS (set MAVEN_OPTS=) it still works for me, so
that's good. I tied the 'mvn test' and 'mvn site'.

After running site, Maven reports:

[INFO] Final Memory: 43M/143M



Did some more testing: the build runs fine for me with Java 1.6, but the
heap space error occurs on Java 1.5 (on Windows 7). Any idea what could be
the source of this problem?



I am good on Java 5 and Windows 7, so I am not sure how to help here.

[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 45.467s
[INFO] Finished at: Mon Dec 05 16:59:48 EST 2011
[INFO] Final Memory: 15M/65M
[INFO]

C:\temp\codec>m3 -version
Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
Maven home: C:\Java\apache-maven-3.0.3\bin\..
Java version: 1.5.0_22, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.5.0_22\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"



Strange. Just for the record, below are my settings. May Java version is 
slightly older. Maybe a bug in the JDK?


Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.5.0_21
Java home: C:\Program Files\Java\jdk1.5.0_21\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"

Oliver


Gary



Oliver



Gary




Oliver


  Gary




  Otherwise, I did not find major problems. The site has two checkstyle

links: one is clean, the other contains errors.

Oliver

Am 03.12.2011 04:06, schrieb Gary Gregory:

  Good day to you all:



I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I
am
not calling it RC3 because there are no changes in source files from
the
last RC. The only difference is that I built from a fresh checkout of
the
RC2 svn tag.

The changes from RC1 are what Sebb found:
- EOL in sources
- Cruft from a dirty build, so I built this RC as I should have the
first
time around with:
 - mvn clean
 - mvn deploy -Prelease

Tag:

https://svn.apache.org/repos/**asf/commons/proper/codec/
tags/**




commons-codec
proper/codec/tags/commons-codec






  -1.6-RC2


Site:

https://people.apache.org/**builds/commons/codec/1.6/RC2/
<**https://people.apache.org/builds/commons/codec/1.6/RC2/



<**https://people.apache.org/builds/commons/codec/1.6/RC2/
**








Binaries:


repositories/orgapachecommons-224/











  
https://repository.apache.org/**content/repositories/**

https://repository.apache.org/**content/repositories/**>



orgapachecommons-290/

[math] Strange deprecations in RealMatrix

2011-12-06 Thread Peter Bloem 
I've recently switched to Commons Math, and I'm quite happy with it, but 
I found the following a little weird.


RealMatrix has some very odd deprecations. In particular inverse(), 
getDeterminant() and isSingular(). The last has the message:


> Deprecated. as of release 2.0, replaced by the boolean negation of 
new LUDecompositionImpl(m).getSolver().isNonSingular()


Surely, that's an implementation, not an interface. The whole point of 
having an interface is that
 a) I can query whether a matrix is singular withou having to know 
about LUDecompositions
 b) You guys can change the implementation of isSingular() if something 
better pops up without us guys having to change our code.


I'm not using these methods now, because they're deprecated, but I've 
basically recreated them as static methods in a utility class. Wouldn't 
it be much better to just put code from the deprecation message into the 
method and remove the deprecation?


regards,
 Peter


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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

2011-12-06 Thread Luc Maisonobe 
Le 05/12/2011 16:14, Christian Grobmeier a écrit :
>> [+1] Yes, you may release the next major release of JEXL3 with a Java6
>> requirement

+1

> 
> I think the maintainers of a component can decide on their own which
> jdk they want to support. If you want to support a newer Java with the
> next big major version of JEXL I give you my +1. For me a major
> version is allowed to break old rules and create new ones.

Agreed.

> 
>> PS: Is there a process to formally move a project from Commons to elsewhere
>> within Apache?

There is a general process for moving to attic, but I don't think this
is what you want. I think there is also a general process to become a
TLP. This is exactly what commons did some years ago, coming from Jakarta.

Luc

> 
> What exactly do you mean? Make JEXL a top level project or move JEXL
> to another toplevel project? Or something completley different?
> 
> To move JEXL out of here, i think you should make up a (good) proposal
> and vote on this list. I can imagine it would go to the incubator to
> build up an community. Anyway I tend to think a component should have
> a pretty good size to stand on its own.
> 
> Cheers
> Christian
> 
>>
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context: 
>> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html
>> Sent from the Commons - Dev mailing list archive at Nabble.com.
>>
>> -
>> 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: [VOTE][email] Release Commons Email 1.3 based on RC2

2011-12-06 Thread Siegfried Goeschl 

Hi Stefan,

sounds good - I will check

Siegfried Goeschl

On 06.12.11 16:52, Stefan Bodewig wrote:

On 2011-12-06, Siegfried Goeschl wrote:


ad RAT - I added a license header for "mime.types" but doing this for
the mail messages is not possible AFAIK since there is no such thing
as a comment for mail messages


Since you use the latest Commons parent you now have access to RAT 0.7
(I think) which allows you to exclude files that you know cannot contain
a license.

Stefan

-
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: [VOTE][email] Release Commons Email 1.3 based on RC2

2011-12-06 Thread Stefan Bodewig 
On 2011-12-06, Siegfried Goeschl wrote:

> ad RAT - I added a license header for "mime.types" but doing this for
> the mail messages is not possible AFAIK since there is no such thing
> as a comment for mail messages

Since you use the latest Commons parent you now have access to RAT 0.7
(I think) which allows you to exclude files that you know cannot contain
a license.

Stefan

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

Re: [VOTE][email] Release Commons Email 1.3 based on RC2

2011-12-06 Thread Siegfried Goeschl 

Hi Gary,

ad RAT - I added a license header for "mime.types" but doing this for 
the mail messages is not possible AFAIK since there is no such thing as 
a comment for mail messages


ad src zip - need to check since I did a last minute upgrade to the 
latest commons-parent.pom


ad Clirr errors - this reported errors are stemming from two changes

1) I introduced an "EmailConstants.java" to collect all the constants 
and Email implements EmailConstants


2) the setter methods of Email return now consistently "this" instead of 
void


IMHO both changes do not break binary compatibility for the minor release

Cheers,

Siegfried Goeschl


On 05.12.11 23:11, Gary Gregory wrote:

Hi Siegfried:

Thank you for preparing the RC.

This /sounds/ worrisome from RAT:

Unapproved  licenses:


   src/resources/META-INF/mime.types

   src/test/eml/attachment-only.eml

   src/test/eml/html-attachment.eml

   src/test/eml/multipart-report.eml

   src/test/eml/simple-reply.eml

   src/test/eml/simple.eml


Where is the 'src' zip I can build from?

Looks like there are three easy to fix checkstyle errors (not the
missing Javadocs.)

-1: Can you justify the 51 Clirr errors in a minor release?

Our current guideline is that such a change means a major version and
new package. I do not care which way we go but we should be mindful of
binary compatibility for minor release.

Thank you,
Gary

On Mon, Dec 5, 2011 at 4:31 PM, Siegfried Goeschl mailto:sgoes...@gmx.at>> wrote:

Hi folks,

I would like to call a vote to release commons-email-1.3 which
contains the following bug fixes and improvements found here


http://people.apache.org/__builds/commons/email/1.3/RC2/__site/changes-report.html



Tag:

https://svn.apache.org/repos/__asf/commons/proper/email/tags/__EMAIL_1_3_RC2


Site:

http://people.apache.org/__builds/commons/email/1.3/RC2/__site/index.html


Binaries:


http://people.apache.org/__builds/commons/email/1.3/RC2/__staged/org/apache/commons/__commons-email/1.3/



[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because

Thanks in advance

Siegfried Goeschl

--__--__-
To unsubscribe, e-mail: dev-unsubscribe@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

[digester] providing additional shaded artifact

2011-12-06 Thread Simone Tripodi 
Hi all guys,
to complete DIGESTER-153 we had to include CGLIB as new dependency,
actually I would like to experiment distributing an *additional*
artifact (jar) where dependencies are shaded - maybe also renamed for
internal use only.
Note that I don't want to replace the existing distribution, I just
would like to add another jar - users could chose to use it instead.
That wouldn't be the first time that a commons component would
distribute more than one artifact anyway, [beanutils] already does
(even if not shading dependencies)
Do you see potential legal/technical issues?
TIA,
-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: [RELEASE PROCESS] Stability versus usability

2011-12-06 Thread henrib 
Hi Jörg;
I've amended the idea based on feedback to *internal* package and @internal
annotation (for pragmatic reasons: a good rule is one which is easy to
follow and enforce). 
The naming convention or the annotation would allow clear but also explicit
boundary; documentation is necessary but not sufficient IMHO. It should be
possible to determine automatically whether "public" code unintentionally
exposes or uses an @internal class by transitivity.
I agree that packaging should be the preferred way but sometimes, it may be
too hard/long/costly to refactor the project; "sprinkling" annotations would
not be ideal but would still allow control over the API stability.
Cheers,
Henrib

PS: We might need @experimental or @beta for APIs intended for public use
but not stable enough to make a hard cast-in-stone stable contract.


--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4164209.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

2011-12-06 Thread Christian Grobmeier 
On Tue, Dec 6, 2011 at 10:45 AM, henrib  wrote:
>
> Matt Benson-2 wrote
>>
>> Maybe the right approach is to start with Java 6, then whoever likes to
>> can
>> investigate how much work it would take to restore Java 5
>> compatibility.
>>
> Seems like a reasonable proposal to me; it means Java 1.5 is a "nice to
> have" feature - not a "must have" - feature as it currently stands.
> If someone needs a Java 1.5 backport, he can contribute to the project by
> doing so. Do-ocracy at work.
> Fair enough?

+1
Exactly that is what I wanted to express. Looks like I can't express very well.

Cheers
Christian

> Cheers
> Henrib
>
> PS: may be at the process/Commons level, we could introduce another category
> for of our projects.
> Instead of the current 3 "Proper, Sandbox, Dormant", something like "Stable
> (1.5-able), Proper, Sandox, Dormant" or "Modern, Proper (1.5 able), Sandbox,
> Dormant". So new versions can go "modern" till the need arise & a
> contribution is made for a "stable" version. Just a thought...
>
>
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4164066.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> -
> 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: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

2011-12-06 Thread henrib 

Matt Benson-2 wrote
> 
> Maybe the right approach is to start with Java 6, then whoever likes to
> can
> investigate how much work it would take to restore Java 5
> compatibility.
> 
Seems like a reasonable proposal to me; it means Java 1.5 is a "nice to
have" feature - not a "must have" - feature as it currently stands.
If someone needs a Java 1.5 backport, he can contribute to the project by
doing so. Do-ocracy at work.
Fair enough?
Cheers
Henrib

PS: may be at the process/Commons level, we could introduce another category
for of our projects.
Instead of the current 3 "Proper, Sandbox, Dormant", something like "Stable
(1.5-able), Proper, Sandox, Dormant" or "Modern, Proper (1.5 able), Sandbox,
Dormant". So new versions can go "modern" till the need arise & a
contribution is made for a "stable" version. Just a thought...



--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4164066.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

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

Re: [Graph] Weighted as an interface

2011-12-06 Thread Simone Tripodi 
Hola Claudio!

for all algorithms implemented in the `shortestpath` package (A*,
Dijkstra, Bellmann-Ford, ...), I didn't have the need to add new
specific methods for {{WeightedGraph}}es since that interface was used
more as a marker - a direct graph, which edges are weighted (granted
by generics), satisfies the algos input as well.

As domain expert you maybe know advanced algorithms that require more
assumptions on the input graph, so any suggestion is welcome!

Simo

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



On Tue, Dec 6, 2011 at 10:11 AM, Claudio Squarcella
 wrote:
> Hi,
>
>
 Moreover, I start having the feeling the {{WeightedGraph}} is a
 useless interface: it is enough marking the vertices/edges as weighted
 depending on the problem... or not? At the end of the day,
 {{WeightedGraph}} does nothing than having the the edges marked as
 weighted, so Dijkstra signature changed as:

 >>> WE>>    WeightedPath    findShortestPath( G graph,  V source, V
 target )

 still define well the input type, a graph wich relations are directed
 edges and edges are weighted... WDYT?
>>>
>>>
>>> I agree, as long as there are no specific features of the graph that are
>>> independent on its vertices and edges.
>
>
> quoting myself here: actually I think {{WeightedGraph}} should *not* go away
> if it makes sense to add methods to it later (e.g. to get the total weight).
> But changing the signature of the methods is still a valid idea, as it
> allows for a more fine-grained expressiveness on the input. Right?
>
> Claudio
>
>
>>> Another advantage: I won't bother
>>> later to add more speficic interfaces like {{EdgeWeightedGraph}} or
>>> {{VertexWeightedGraph}} ;-)
>>>
>> +1, please include that in a separate issue!
>> All the best, have a nice day!
>> Simo
>>
>>> Ciao,
>>> Claudio
>>
>> 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
>>
>
> --
> Claudio Squarcella
> PhD student at Roma Tre University
> E-mail address: squar...@dia.uniroma3.it
> Phone: +39-06-57333215
> Fax: +39-06-57333612
> http://www.dia.uniroma3.it/~squarcel
>
>
> -
> 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: [Graph] Weighted as an interface

2011-12-06 Thread Claudio Squarcella 

Hi,


Moreover, I start having the feeling the {{WeightedGraph}} is a
useless interface: it is enough marking the vertices/edges as weighted
depending on the problem... or not? At the end of the day,
{{WeightedGraph}} does nothing than having the the edges marked as
weighted, so Dijkstra signature changed as:

>WeightedPathfindShortestPath( G graph,  V source, V
target )

still define well the input type, a graph wich relations are directed
edges and edges are weighted... WDYT?


I agree, as long as there are no specific features of the graph that are
independent on its vertices and edges.


quoting myself here: actually I think {{WeightedGraph}} should *not* go 
away if it makes sense to add methods to it later (e.g. to get the total 
weight). But changing the signature of the methods is still a valid 
idea, as it allows for a more fine-grained expressiveness on the input. 
Right?


Claudio



Another advantage: I won't bother
later to add more speficic interfaces like {{EdgeWeightedGraph}} or
{{VertexWeightedGraph}} ;-)


+1, please include that in a separate issue!
All the best, have a nice day!
Simo


Ciao,
Claudio

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



--
Claudio Squarcella
PhD student at Roma Tre University
E-mail address: squar...@dia.uniroma3.it
Phone: +39-06-57333215
Fax: +39-06-57333612
http://www.dia.uniroma3.it/~squarcel


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

Re: svn commit: r1210678 - in /commons/proper/digester/trunk/src: main/java/org/apache/commons/digester3/binder/ test/resources/org/apache/commons/digester3/xmlrules/

2011-12-06 Thread Simone Tripodi 
Hi Matt!!

indeed the commit contains too much informations here, I changed the
XML config just to see if the ClassLoader adapter is able to load
primitives by name, just moving the code you committed in the
ObjectCreate builder, so shared classloader across multiple binding is
able to provide the same feature.

I need to provide more specific testcase for that feature :P

Thanks for reviewing, really appreciated!

Simo

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



On Mon, Dec 5, 2011 at 11:37 PM, Matt Benson  wrote:
> Note that in the testcase XML you don't need @params if you're using
> the (boolean, double) constructor.  The default constructor arguments
> were needed to avoid the NPEs that were thrown due to the (Boolean,
> Double) constructor calling { this( booleanProperty.booleanValue(),
> doubleProperty.doubleValue() ); }
>
> Matt
>
> On Mon, Dec 5, 2011 at 4:27 PM,   wrote:
>> Author: simonetripodi
>> Date: Mon Dec  5 22:27:50 2011
>> New Revision: 1210678
>>
>> URL: http://svn.apache.org/viewvc?rev=1210678&view=rev
>> Log:
>> [DIGESTER-154] The DigesterBinder is not able to load primitive classes by 
>> name
>>
>> Added:
>>    
>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
>>    (with props)
>> Modified:
>>    
>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/DigesterLoader.java
>>    
>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/ObjectCreateBuilder.java
>>    
>> commons/proper/digester/trunk/src/test/resources/org/apache/commons/digester3/xmlrules/constructor-testrules.xml
>>
>> Added: 
>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java?rev=1210678&view=auto
>> ==
>> --- 
>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
>>  (added)
>> +++ 
>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
>>  Mon Dec  5 22:27:50 2011
>> @@ -0,0 +1,71 @@
>> +package org.apache.commons.digester3.binder;
>> +
>> +import java.util.Collections;
>> +import java.util.HashMap;
>> +import java.util.Map;
>> +
>> +/*
>> + * Licensed to the Apache Software Foundation (ASF) under one
>> + * or more contributor license agreements.  See the NOTICE file
>> + * distributed with this work for additional information
>> + * regarding copyright ownership.  The ASF licenses this file
>> + * to you under the Apache License, Version 2.0 (the
>> + * "License"); you may not use this file except in compliance
>> + * with the License.  You may obtain a copy of the License at
>> + *
>> + *   http://www.apache.org/licenses/LICENSE-2.0
>> + *
>> + * Unless required by applicable law or agreed to in writing,
>> + * software distributed under the License is distributed on an
>> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>> + * KIND, either express or implied.  See the License for the
>> + * specific language governing permissions and limitations
>> + * under the License.
>> + */
>> +
>> +final class BinderClassLoader
>> +    extends ClassLoader
>> +{
>> +
>> +    private static final Map> PRIMITIVE_TYPES;
>> +    static
>> +    {
>> +        HashMap> primitiveTypes = new HashMap> Class>();
>> +        primitiveTypes.put( "boolean", boolean.class );
>> +        primitiveTypes.put( "byte", byte.class );
>> +        primitiveTypes.put( "short", short.class );
>> +        primitiveTypes.put( "int", int.class );
>> +        primitiveTypes.put( "char", char.class );
>> +        primitiveTypes.put( "long", long.class );
>> +        primitiveTypes.put( "float", float.class );
>> +        primitiveTypes.put( "double", double.class );
>> +        PRIMITIVE_TYPES = Collections.unmodifiableMap( primitiveTypes );
>> +    }
>> +
>> +    private final ClassLoader adaptedClassLoader;
>> +
>> +    public BinderClassLoader( ClassLoader adaptedClassLoader )
>> +    {
>> +        this.adaptedClassLoader = adaptedClassLoader;
>> +    }
>> +
>> +    public ClassLoader getAdaptedClassLoader()
>> +    {
>> +        return adaptedClassLoader;
>> +    }
>> +
>> +    /**
>> +     * {@inheritDoc}
>> +     */
>> +    @Override
>> +    protected synchronized Class loadClass( String name, boolean resolve 
>> )
>> +        throws ClassNotFoundException
>> +    {
>> +        if ( PRIMITIVE_TYPES.containsKey( name ) )
>> +        {
>> +            return PRIMITIVE_TYPES.get( name );
>> +        }
>> +        return adaptedClassLoader.loadClass( name );
>> +    }
>> +
>> +}
>>
>> Propchange: 
>> commons/proper/digester/trunk/src/main/java/org/apache/commons/dig