[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 259 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: 11 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.004 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 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.014 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.011 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.18 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.011 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: Mon Dec 05 05:33:30 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.o

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


Full details are available at:

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

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/exec/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html
Work Name: build_apache-commons_commons-exec-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 23 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/exec]
M2_HOME: /opt/maven2
-
FOO..
gdal_translate
HDF5:"/home/kk/grass/data/4404.he5"://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif
FOO..
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.020 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.026 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.026 ms
Process completed in 2004 millis; below is its output
Process timed out and was killed by watchdog.
org.apache.commons.exec.ExecuteException: Process exited with an error: 143 
(Exit value: 143)
Process completed in 2005 millis; below is its output
Process timed out and was killed.
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
Executing [sh, -c, src/test/scripts/invoker.sh]
invoker.sh -- going to start daemon process
invoker.sh --  daemon process was started
cd: 21: can't cd to ../../../target
Process completed in 8018 millis; above is its output
0: process has terminated: false
1: process has terminated: false
2: process has terminated: false
3: process has terminated: false
4: process has terminated: false
5: process has terminated: false
Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.221 sec <<< 
FAILURE!

Results :

Failed tests: 
  testExec_60(org.apache.commons.exec.DefaultExecutorTest)

Tests run: 95, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/exec/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 22 seconds
[INFO] Finished at: Mon Dec 05 02:38:02 UTC 2011
[INFO] Final Memory: 25M/65M
[INFO] 
-

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

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 1405122011, vmgump.apache.org:vmgump:1405122011
Gump E-mail Identifier (unique within run) #18.

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

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

Re: [Graph] Weighted as an interface

[James Carman]

Welcome!  Contributions (and the contributor) are always welcome.  In my
past life, I did quite a bit of graph programming to solve "business"
problems.  We used yfiles, though.  I hope to get around to playing with
[graph] someday too.  Please do submit a patch!
On Dec 4, 2011 6:43 PM, "Claudio Squarcella" 
wrote:

> Hello,
>
> I have been reading the source in the past days and I found that the
> concept of "weight" (e.g. weighted edge, graph, etc) could benefit from a
> bit of abstraction.
>
> The basic idea would be to have an interface called Weighted with an
> obvious method getWeight(). Changes in the code would easily derive from
> that. As a side effect it would be easy to implement new stuff like
> weighted vertices: not as glorious as weighted edges, but still needed in
> some problems (e.g. all-pairs bottleneck paths) and therefore desirable for
> a general purpose graph API.
>
> One step further. A weight is not necessarily a double: in some cases not
> even a number, but rather a "comparable" of some sort. So I would suggest
> to make use of generics in some way, possibly the smartest. Suggestions are
> welcome :-)
>
> If my thoughts meet some interest I will work on a patch.
>
> Ciao,
> Claudio
>
>
> P.S.
> I am a first-timer here, so what follows is a short introduction.
> I am doing a PhD in Graph Drawing and Information Visualization. I always
> looked for a standard, unified way to represent and handle graphs when
> developing prototypes. So my interest in this project is quite natural, and
> I am willing to help and see it become a robust project.
>
> --
> 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-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[Graph] Weighted as an interface

[Claudio Squarcella]

Hello,

I have been reading the source in the past days and I found that the 
concept of "weight" (e.g. weighted edge, graph, etc) could benefit from 
a bit of abstraction.


The basic idea would be to have an interface called Weighted with an 
obvious method getWeight(). Changes in the code would easily derive from 
that. As a side effect it would be easy to implement new stuff like 
weighted vertices: not as glorious as weighted edges, but still needed 
in some problems (e.g. all-pairs bottleneck paths) and therefore 
desirable for a general purpose graph API.


One step further. A weight is not necessarily a double: in some cases 
not even a number, but rather a "comparable" of some sort. So I would 
suggest to make use of generics in some way, possibly the smartest. 
Suggestions are welcome :-)


If my thoughts meet some interest I will work on a patch.

Ciao,
Claudio


P.S.
I am a first-timer here, so what follows is a short introduction.
I am doing a PhD in Graph Drawing and Information Visualization. I 
always looked for a standard, unified way to represent and handle graphs 
when developing prototypes. So my interest in this project is quite 
natural, and I am willing to help and see it become a robust project.


--
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: [jira] [Created] (JEXL-123) Redesign API for stability

[sebb]

On 4 December 2011 19:57, henrib  wrote:
>
> sebb-2-2 wrote
>>
>>
>>> Since it is targeted at new projects or at least very active ones, the
>>> deployment will require at least Java 1.6.
>>
>> Now if 1.6 is absolutely required to support certain new features,
>> that is a different matter.
>>
>>
> I should have said that 'not useful' too.

No idea what that refers to.

> I believe it is not useful to incur the cost of maintaining knowledge about
> 1.5 and 1.6 differences in this case.

Not sure I understand what the cost is here.

> I also think that if you want to use "new" stuff, it is better to avoid
> putting it on top of unsupported ones (1.5 is eol afaik); instead of
> adapting some code to Jexl3, someone would be doing a better job at
> migrating towards Java 6.

But code that runs on Java 5 will run on Java 6; there's no need to
"migrate" to Java 6.

> Henrib
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4157896.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

[continuum] BUILD FAILURE: Apache Commons - Commons Email - Default Maven 2 Build Definition (Java 1.5)

[Continuum@vmbuild]

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=15386&projectId=79

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Sun 4 Dec 2011 22:20:35 +
  Finished at: Sun 4 Dec 2011 22:21:35 +
  Total time: 1m 0s
  Build Trigger: Schedule
  Build Number: 30
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_26"
  Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
  Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

  Builder version :
  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
  Java version: 1.6.0_26
  Java home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre
  Default locale: en_US, platform encoding: UTF-8
  OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: 
"unix"


SCM Changes:

Changed: sgoeschl @ Sun 4 Dec 2011 21:44:00 +
Comment: Cleaning up the code
Files changed:
  /commons/proper/email/trunk/NOTICE.txt ( 1210236 )
  /commons/proper/email/trunk/pom.xml ( 1210236 )
  
/commons/proper/email/trunk/src/java/org/apache/commons/mail/ImageHtmlEmail.java
 ( 1210236 )
  
/commons/proper/email/trunk/src/java/org/apache/commons/mail/resolver/DataSourceClassPathResolver.java
 ( 1210236 )
  
/commons/proper/email/trunk/src/java/org/apache/commons/mail/resolver/DataSourceFileResolver.java
 ( 1210236 )
  
/commons/proper/email/trunk/src/java/org/apache/commons/mail/util/MimeMessageParser.java
 ( 1210236 )

Changed: sgoeschl @ Sun 4 Dec 2011 22:08:29 +
Comment: Cleaning up the code
Files changed:
  /commons/proper/email/trunk/src/java/org/apache/commons/mail/Email.java ( 
1210249 )
  
/commons/proper/email/trunk/src/java/org/apache/commons/mail/resolver/DataSourceFileResolver.java
 ( 1210249 )

Changed: sgoeschl @ Sun 4 Dec 2011 22:09:07 +
Comment: Upgrading to mail-1.4.4 and activation-1.1.1
Files changed:
  /commons/proper/email/trunk/pom.xml ( 1210251 )

Changed: sgoeschl @ Sun 4 Dec 2011 22:10:14 +
Comment: Cleaning up the code
Files changed:
  /commons/proper/email/trunk/src/changes/changes.xml ( 1210253 )

Changed: sgoeschl @ Sun 4 Dec 2011 22:12:03 +
Comment: Preparing release
Files changed:
  /commons/proper/email/trunk/RELEASE-NOTES.txt ( 1210254 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean deploy   
Arguments: --batch-mode -Pjava-1.5
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 2.2.1
Description: Default Maven 2 Build Definition (Java 1.5)


Test Summary:

Tests: 123
Failures: 7
Errors: 0
Success Rate: 94
Total time: 4.6629996


Test Failures:


InvalidInternetAddressTest
testStrictConstructor :
  junit.framework.AssertionFailedError
  junit.framework.AssertionFailedError: Strict 10 passed: local\n...@domain.com
at junit.framework.Assert.fail(Assert.java:47)
at 
org.apache.commons.mail.InvalidInternetAddressTest.testStrictConstructor(InvalidInternetAddressTest.java:120)


testValidateMethod :
  junit.framework.AssertionFailedError
  junit.framework.AssertionFailedError: Validate 10 passed: 
local\n...@domain.com
at junit.framework.Assert.fail(Assert.java:47)
at 
org.apache.commons.mail.InvalidInternetAddressTest.testValidateMethod(InvalidInternetAddressTest.java:176)


testValidateMethodCharset :
  junit.framework.AssertionFailedError
  junit.framework.AssertionFailedError: Validate 10 passed: 
local\n...@domain.com
at junit.framework.Assert.fail(Assert.java:47)
at 
org.apache.commons.mail.InvalidInternetAddressTest.testValidateMethodCharset(InvalidInternetAddressTest.java:233)

  InvalidAddressTest
testSetInvalidFrom :
  junit.framework.AssertionFailedError
  junit.framework.AssertionFailedError: setFrom 10 passed: local\n...@domain.com
at junit.framework.Assert.fail(Assert.java:47)
at 
org.apache.commons.mail.InvalidAddressTest.testSetInvalidFrom(InvalidAddressTest.java:105)


testAddInvalidTo :
  junit.framework.AssertionFailedError
  junit.framework.AssertionFailedError: addTo 1

Re: [JEXL] [PreVOTE] OK to release Jexl with some Clirr errors but no package/id change?

[luc . maisonobe]

- Mail original -
> The Jexl 2.0 branch now has only a few incompatibilities reported by
> Clirr (see below).
> 
> Also the 2.0.1 JUnit tests now run (with minor essential changes)
> against both 2.0.1 and 2.1-SNAPSHOT.
> 
> The remaining errors all relate to adding methods to interfaces.
> According to the JLS [1], adding methods to an interface does not
> break *binary* compatibility; however of course it will break source
> compatibility.
> I assume that Clirr has got this wrong; or is failing to distinguish
> source compatibility from binary compatibility.
> There is a test case to show this -
> ScriptTest.testScriptInterfaceBinaryCompat() - in the
> COMMONS_JEXL_2_0_1_TEST branch.
> 
> I think it would be OK to release the code without changing package
> names / Maven id if other Commons developers agree.
> What do others think?

I think it would be OK to release as 2.1, but if anybody else think 3.0 is 
better, then go for it.

Luc

> 
> Assuming that there are no objections, there is the question of what
> version to use.
> 
> The changes clearly require at least a minor version bump, i.e. 2.1
> rather than 2.0.2.
> It is unlikely that any users will have implemented the Script
> interface directly; any that have done so will need to update their
> source before recompiling.
> Does such a source incompatibility require a major version bump to
> 3.0?
> [Note: this does *not* mean a package change is required; however a
> package change would require a major version bump]
> 
> I think this discussion is best held separately from any release
> vote,
> as there are always plenty of other items to check in a release
> vote...
> 
> =
> 
> ERROR: 7012: org.apache.commons.jexl2.introspection.Uberspect: Method
> 'public org.apache.commons.jexl2.introspection.JexlMethod
> getConstructorMethod(java.lang.Object, java.lang.Object[],
> org.apache.commons.jexl2.JexlInfo)' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.JexlInfo: Method 'public
> org.apache.commons.jexl2.DebugInfo debugInfo()' has been added to an
> interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.lang.Object execute(org.apache.commons.jexl2.JexlContext,
> java.lang.Object[])' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.lang.String[] getLocalVariables()' has been added to an
> interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.lang.String[] getParameters()' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.util.concurrent.Callable
> callable(org.apache.commons.jexl2.JexlContext)' has been added to an
> interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.util.concurrent.Callable
> callable(org.apache.commons.jexl2.JexlContext, java.lang.Object[])'
> has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.util.Set getVariables()' has been added to an interface
> 
> [1]
> http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#45347
> 
> -
> 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][Codec] Release Commons Codec 1.6-RC2 REDUX

[Oliver Heger]

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?


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



-1.6-RC2

Site:

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




Binaries:










https://repository.apache.org/content/repositories/**
orgapachecommons-290/





The link above includes checksum files.

[ ] +1 release it
[ ] +0 go ahead, I cannot take the time
[ ] -1 no, do not release it because:

This VOTE is open for 72 hours, until November 23 2011, 14:00 EST.

Fixed Bugs:
o Use standard Maven directory layout.  Issue: CODEC-129. Thanks to
ggregory.
o Documentation spelling fixes.  Issue: CODEC-128. Thanks
toville.sky...@iki.fi

.
o Fix various character encoding issues in comments and test cases.
  Issue:
CODEC-127.
o ColognePhonetic Javadoc should use HTML entities for special
characters.
Issue: CODEC-123.

Changes:
o Implement a Beider-Morse phonetic matching codec.  Issue: CODEC-125.
Thanks to Matthew Pocock.
o Migrate to Java 5.  Issue: CODEC-119.
o Migrate to JUnit 4.  Issue: CODEC-120.

Heads up: the Beider-Morse encoder tests take a long time to run (5
minutes). The code has been optimized.

Thank you,
Gary




--**
--**-
To unsubscribe, e-mail: 
dev-unsubscribe@commons.**apac**he.org





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








--**--**-
To unsubscribe, e-mail: 
dev-unsubscribe@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: [jira] [Created] (JEXL-123) Redesign API for stability

[henrib]

sebb-2-2 wrote
> 
> 
>> Since it is targeted at new projects or at least very active ones, the
>> deployment will require at least Java 1.6.
> 
> Now if 1.6 is absolutely required to support certain new features,
> that is a different matter.
> 
> 
I should have said that 'not useful' too.
I believe it is not useful to incur the cost of maintaining knowledge about
1.5 and 1.6 differences in this case.
I also think that if you want to use "new" stuff, it is better to avoid
putting it on top of unsupported ones (1.5 is eol afaik); instead of
adapting some code to Jexl3, someone would be doing a better job at
migrating towards Java 6.
Henrib

--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4157896.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: [jira] [Created] (JEXL-123) Redesign API for stability

[sebb]

On 4 December 2011 19:08, Henri Biestro (Created) (JIRA)
 wrote:
> Redesign API for stability
> --
>
>                 Key: JEXL-123
>                 URL: https://issues.apache.org/jira/browse/JEXL-123
>             Project: Commons JEXL
>          Issue Type: Improvement
>            Reporter: Henri Biestro
>            Assignee: Henri Biestro
>            Priority: Critical

??

>
>
> 2.1 has shown it was very difficult to evolve the features without 
> compromising stability, i.e. respecting the contract made by the API.
> 3.0 main goal is to make the API stable, making clear where the difference is 
> between "using" Jexl and "customizing/improving" Jexl.

OK, fine.

> Since it is targeted at new projects or at least very active ones, the 
> deployment will require at least Java 1.6.

I don't see how it follows that Java 1.6 is required.

Pool and Math have been extensively reworked recently for similar
reasons and neither was changed to require 1.6.

Now if 1.6 is absolutely required to support certain new features,
that is a different matter.

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

Re: [JEXL] [PreVOTE] OK to release Jexl with some Clirr errors but no package/id change?

[henrib]

+1 :-)

I honestly believe it is safe and that we are not making a dis-service to
the Jexl community.
Thanks again for your hard efforts in keeping the package name as-is on
their behalf.
Best regards,
Henrib

--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/JEXL-PreVOTE-OK-to-release-Jexl-with-some-Clirr-errors-but-no-package-id-change-tp4157709p4157751.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: [JEXL] [PreVOTE] OK to release Jexl with some Clirr errors but no package/id change?

[Gary Gregory]

+1 to release as 3.0, breaking any compat should be major. New package
seems safer but I would not -1 a release as is.

G

On Sun, Dec 4, 2011 at 1:59 PM, sebb  wrote:

> The Jexl 2.0 branch now has only a few incompatibilities reported by
> Clirr (see below).
>
> Also the 2.0.1 JUnit tests now run (with minor essential changes)
> against both 2.0.1 and 2.1-SNAPSHOT.
>
> The remaining errors all relate to adding methods to interfaces.
> According to the JLS [1], adding methods to an interface does not
> break *binary* compatibility; however of course it will break source
> compatibility.
> I assume that Clirr has got this wrong; or is failing to distinguish
> source compatibility from binary compatibility.
> There is a test case to show this -
> ScriptTest.testScriptInterfaceBinaryCompat() - in the
> COMMONS_JEXL_2_0_1_TEST branch.
>
> I think it would be OK to release the code without changing package
> names / Maven id if other Commons developers agree.
> What do others think?
>
> Assuming that there are no objections, there is the question of what
> version to use.
>
> The changes clearly require at least a minor version bump, i.e. 2.1
> rather than 2.0.2.
> It is unlikely that any users will have implemented the Script
> interface directly; any that have done so will need to update their
> source before recompiling.
> Does such a source incompatibility require a major version bump to 3.0?
> [Note: this does *not* mean a package change is required; however a
> package change would require a major version bump]
>
> I think this discussion is best held separately from any release vote,
> as there are always plenty of other items to check in a release
> vote...
>
> =
>
> ERROR: 7012: org.apache.commons.jexl2.introspection.Uberspect: Method
> 'public org.apache.commons.jexl2.introspection.JexlMethod
> getConstructorMethod(java.lang.Object, java.lang.Object[],
> org.apache.commons.jexl2.JexlInfo)' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.JexlInfo: Method 'public
> org.apache.commons.jexl2.DebugInfo debugInfo()' has been added to an
> interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.lang.Object execute(org.apache.commons.jexl2.JexlContext,
> java.lang.Object[])' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.lang.String[] getLocalVariables()' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.lang.String[] getParameters()' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.util.concurrent.Callable
> callable(org.apache.commons.jexl2.JexlContext)' has been added to an
> interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.util.concurrent.Callable
> callable(org.apache.commons.jexl2.JexlContext, java.lang.Object[])'
> has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.util.Set getVariables()' has been added to an interface
>
> [1]
> http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#45347
>
> -
> 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

[JEXL] [PreVOTE] OK to release Jexl with some Clirr errors but no package/id change?

[sebb]

The Jexl 2.0 branch now has only a few incompatibilities reported by
Clirr (see below).

Also the 2.0.1 JUnit tests now run (with minor essential changes)
against both 2.0.1 and 2.1-SNAPSHOT.

The remaining errors all relate to adding methods to interfaces.
According to the JLS [1], adding methods to an interface does not
break *binary* compatibility; however of course it will break source
compatibility.
I assume that Clirr has got this wrong; or is failing to distinguish
source compatibility from binary compatibility.
There is a test case to show this -
ScriptTest.testScriptInterfaceBinaryCompat() - in the
COMMONS_JEXL_2_0_1_TEST branch.

I think it would be OK to release the code without changing package
names / Maven id if other Commons developers agree.
What do others think?

Assuming that there are no objections, there is the question of what
version to use.

The changes clearly require at least a minor version bump, i.e. 2.1
rather than 2.0.2.
It is unlikely that any users will have implemented the Script
interface directly; any that have done so will need to update their
source before recompiling.
Does such a source incompatibility require a major version bump to 3.0?
[Note: this does *not* mean a package change is required; however a
package change would require a major version bump]

I think this discussion is best held separately from any release vote,
as there are always plenty of other items to check in a release
vote...

=

ERROR: 7012: org.apache.commons.jexl2.introspection.Uberspect: Method
'public org.apache.commons.jexl2.introspection.JexlMethod
getConstructorMethod(java.lang.Object, java.lang.Object[],
org.apache.commons.jexl2.JexlInfo)' has been added to an interface
ERROR: 7012: org.apache.commons.jexl2.JexlInfo: Method 'public
org.apache.commons.jexl2.DebugInfo debugInfo()' has been added to an
interface
ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
java.lang.Object execute(org.apache.commons.jexl2.JexlContext,
java.lang.Object[])' has been added to an interface
ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
java.lang.String[] getLocalVariables()' has been added to an interface
ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
java.lang.String[] getParameters()' has been added to an interface
ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
java.util.concurrent.Callable
callable(org.apache.commons.jexl2.JexlContext)' has been added to an
interface
ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
java.util.concurrent.Callable
callable(org.apache.commons.jexl2.JexlContext, java.lang.Object[])'
has been added to an interface
ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
java.util.Set getVariables()' has been added to an interface

[1] 
http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#45347

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

Re: [JEXL] Are users likely to implement the Script interface?

[sebb]

On 4 December 2011 18:46, henrib  wrote:
>
> sebb-2-2 wrote
>>
>> Don't know if this is an indication that the unit tests are incomplete
>> or that there is not really a use case for implementing the interface,
>> (other than the implementations which are already supplied.)
>>
> I don't think anyone would implement the Script interface without deriving /
> delegating to an ExpressionImpl which is internal (by transitivity from the
> protected ASTJexlScript member); so it'b be someone trying to extend Jexl
> capabilities.
> Jexl being usually featured and used as a glue / joint, JEXL Scripts are
> usually used as classes members thus implementing Script is very unlikely.

OK, thanks.

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

Re: [JEXL] Are users likely to implement the Script interface?

[henrib]

sebb-2-2 wrote
> 
> Don't know if this is an indication that the unit tests are incomplete
> or that there is not really a use case for implementing the interface,
> (other than the implementations which are already supplied.)
> 
I don't think anyone would implement the Script interface without deriving /
delegating to an ExpressionImpl which is internal (by transitivity from the
protected ASTJexlScript member); so it'b be someone trying to extend Jexl
capabilities.
Jexl being usually featured and used as a glue / joint, JEXL Scripts are
usually used as classes members thus implementing Script is very unlikely.
I've been working on a redesign of the API for a potential V3 - a fresh and
clean API made to be stable but breaking free from the "ancient" Velocity
ties - and moved the ExpressionImpl equivalent to an internal package; I'll
commit soon in the trunk, tests ok, Checkstyle stuff remains mainly.
Cheers,
Henrib


--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/JEXL-Are-users-likely-to-implement-the-Script-interface-tp4157600p4157664.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

[JEXL] Are users likely to implement the Script interface?

[sebb]

As the subject says - how likely is it that users will have
implemented the Script interface?
There are no unit test cases that do (apart from the one I added to
check for binary compat).
Don't know if this is an indication that the unit tests are incomplete
or that there is not really a use case for implementing the interface,
(other than the implementations which are already supplied.)

Any idea?

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

Re: [dbutils] Releasing 1.5

[sebb]

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.

> Thanks...
>
> Bill-
>
> On Sun, Dec 4, 2011 at 11:03 AM, sebb  wrote:
>> On 3 December 2011 18:11, Gary Gregory  wrote:
>>> On Sat, Dec 3, 2011 at 12:04 PM, William Speirs  wrote:
>>>
 I took a look at the Continuum build error from Nov 26th and the error is
 that adding getSQLXML() in BeanProcessor.java requires
 importing java.sql.SQLXML which was introduced in Java 1.6.

 Currently DBUTILS is set to only require Java 1.5.
>>
>> Should remain so if at all possible.
>>

 Thoughts?

>>>
>>> Require Java 6! :)
>>> Gary
>>>
>>>

 Bill-

 On Sat, Nov 26, 2011 at 4:09 PM, Simone Tripodi >>> >wrote:

 > Hi Bill,
 > Continuum just notified a build failure :P
 > If you intend to cut a new release, read our `Creating Releases` page
 > on wiki[1], count on me if you need help (I was the last on cutting a
 > DbUtils release)
 > Have a nice weekend, all the best!
 > Simo
 >
 > [1] http://wiki.apache.org/commons/CreatingReleases
 >
 > http://people.apache.org/~simonetripodi/
 > http://simonetripodi.livejournal.com/
 > http://twitter.com/simonetripodi
 > http://www.99soft.org/
 >
 >
 >
 > On Sat, Nov 26, 2011 at 9:22 PM, Bill Speirs 
 > wrote:
 > > Does anyone have thoughts on releasing commons-dbutils 1.5? There are
 > > 5 changes since 1.4 (issues 84, 77, 73, 67, and 66), and I think
 > > that's probably enough to warrant a new release.
 > >
 > > I'm new to this whole process, so I'm unsure as to what to do next.
 > >
 > > Thanks...
 > >
 > > Bill-
 > >
 > > -
 > > 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
>>
>
> -
> 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: [dbutils] Releasing 1.5

[William Speirs]

What is the "rule" on when you can switch Java versions? Is going from
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?

Thanks...

Bill-

On Sun, Dec 4, 2011 at 11:03 AM, sebb  wrote:
> On 3 December 2011 18:11, Gary Gregory  wrote:
>> On Sat, Dec 3, 2011 at 12:04 PM, William Speirs  wrote:
>>
>>> I took a look at the Continuum build error from Nov 26th and the error is
>>> that adding getSQLXML() in BeanProcessor.java requires
>>> importing java.sql.SQLXML which was introduced in Java 1.6.
>>>
>>> Currently DBUTILS is set to only require Java 1.5.
>
> Should remain so if at all possible.
>
>>>
>>> Thoughts?
>>>
>>
>> Require Java 6! :)
>> Gary
>>
>>
>>>
>>> Bill-
>>>
>>> On Sat, Nov 26, 2011 at 4:09 PM, Simone Tripodi >> >wrote:
>>>
>>> > Hi Bill,
>>> > Continuum just notified a build failure :P
>>> > If you intend to cut a new release, read our `Creating Releases` page
>>> > on wiki[1], count on me if you need help (I was the last on cutting a
>>> > DbUtils release)
>>> > Have a nice weekend, all the best!
>>> > Simo
>>> >
>>> > [1] http://wiki.apache.org/commons/CreatingReleases
>>> >
>>> > http://people.apache.org/~simonetripodi/
>>> > http://simonetripodi.livejournal.com/
>>> > http://twitter.com/simonetripodi
>>> > http://www.99soft.org/
>>> >
>>> >
>>> >
>>> > On Sat, Nov 26, 2011 at 9:22 PM, Bill Speirs 
>>> > wrote:
>>> > > Does anyone have thoughts on releasing commons-dbutils 1.5? There are
>>> > > 5 changes since 1.4 (issues 84, 77, 73, 67, and 66), and I think
>>> > > that's probably enough to warrant a new release.
>>> > >
>>> > > I'm new to this whole process, so I'm unsure as to what to do next.
>>> > >
>>> > > Thanks...
>>> > >
>>> > > Bill-
>>> > >
>>> > > -
>>> > > 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
>

-
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

[sebb]

On 4 December 2011 10:41, henrib  wrote:
> Keeping track as it evolves based on feedback;
>
> Goal is to allow easy definition, usage and check of stable APIs.

+1, agree that we need to be clearer about what the intended external API is.

> An annotation and a package naming convention allow the project developer to
> clearly state when a class/method/field is not part of the stable contract
> despite a public/protected declaration but only of the internal part of the
> project.

+1

> @internal annotated class/method or *internal* package mean "use this at
> your own maintenance cost"; those are not part of the "public" API. They can
> be used and extended but are subject to change between versions without
> @deprecated annotations.

+1.

I prefer the use of a separate internal/experimental package name;
seems much more obvious than an embedded annotation.
Also much more obvious when setting up Clirr exclusions.

I think it's worth having both internal and experimental packages (and
annotations):
- internal = not likely ever to be part of the external API
- experimental = may one day become part of the external API

However, I'm not yet sure how we get around the binary
incompatibilities that result from renaming a package to internal or
experimental (the reverse should be OK, as we don't promise anything)

> Those annotations and conventions should allow feeding a clirr report with
> the proper information to allow detection of unintended API breakage and may
> even allow creating IDE plugins to warn about usage.

Clirr can already be told to ignore packages and classes.
If it were possible to control this via annotations, I would hope that
the report would show which classes had been excluded from
consideration.
At least with explicit exclusions in the POM it's fairly easy to see
this information in one place.

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

Re: [dbutils] Releasing 1.5

[sebb]

On 3 December 2011 18:11, Gary Gregory  wrote:
> On Sat, Dec 3, 2011 at 12:04 PM, William Speirs  wrote:
>
>> I took a look at the Continuum build error from Nov 26th and the error is
>> that adding getSQLXML() in BeanProcessor.java requires
>> importing java.sql.SQLXML which was introduced in Java 1.6.
>>
>> Currently DBUTILS is set to only require Java 1.5.

Should remain so if at all possible.

>>
>> Thoughts?
>>
>
> Require Java 6! :)
> Gary
>
>
>>
>> Bill-
>>
>> On Sat, Nov 26, 2011 at 4:09 PM, Simone Tripodi > >wrote:
>>
>> > Hi Bill,
>> > Continuum just notified a build failure :P
>> > If you intend to cut a new release, read our `Creating Releases` page
>> > on wiki[1], count on me if you need help (I was the last on cutting a
>> > DbUtils release)
>> > Have a nice weekend, all the best!
>> > Simo
>> >
>> > [1] http://wiki.apache.org/commons/CreatingReleases
>> >
>> > http://people.apache.org/~simonetripodi/
>> > http://simonetripodi.livejournal.com/
>> > http://twitter.com/simonetripodi
>> > http://www.99soft.org/
>> >
>> >
>> >
>> > On Sat, Nov 26, 2011 at 9:22 PM, Bill Speirs 
>> > wrote:
>> > > Does anyone have thoughts on releasing commons-dbutils 1.5? There are
>> > > 5 changes since 1.4 (issues 84, 77, 73, 67, and 66), and I think
>> > > that's probably enough to warrant a new release.
>> > >
>> > > I'm new to this whole process, so I'm unsure as to what to do next.
>> > >
>> > > Thanks...
>> > >
>> > > Bill-
>> > >
>> > > -
>> > > 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: [JEXL] remaining binary incompatibilities in 2.1

[sebb]

On 3 December 2011 14:52, henrib  wrote:
> If the last hurdle to binary compatibility is replacing DebugInfo by
> JexlInfo, by all means, replace it!

OK, will do.

> Nice analysis and great result.

Thanks.
At times it looked as though the changes were too great to restore
compatibility, but I think we're there now.

> Thanks for your efforts,
> Cheers
> Henrib
>
> Ps any comment on the difference between stability and usability and
> possible solutions, cd release process post?

Been busy; still thiking about that.

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

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

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


Full details are available at:

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

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/exec/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html
Work Name: build_apache-commons_commons-exec-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 23 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/exec]
M2_HOME: /opt/maven2
-
FOO..
gdal_translate
HDF5:"/home/kk/grass/data/4404.he5"://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif
FOO..
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.020 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.025 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.025 ms
Process completed in 2004 millis; below is its output
Process timed out and was killed by watchdog.
org.apache.commons.exec.ExecuteException: Process exited with an error: 143 
(Exit value: 143)
Process completed in 2005 millis; below is its output
Process timed out and was killed.
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
Executing [sh, -c, src/test/scripts/invoker.sh]
invoker.sh -- going to start daemon process
invoker.sh --  daemon process was started
cd: 21: can't cd to ../../../target
Process completed in 8018 millis; above is its output
0: process has terminated: false
1: process has terminated: false
2: process has terminated: false
3: process has terminated: false
4: process has terminated: false
5: process has terminated: false
Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.852 sec <<< 
FAILURE!

Results :

Failed tests: 
  testExec_60(org.apache.commons.exec.DefaultExecutorTest)

Tests run: 95, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/exec/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 22 seconds
[INFO] Finished at: Sun Dec 04 14:36:29 UTC 2011
[INFO] Final Memory: 25M/65M
[INFO] 
-

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

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 05001204122011, vmgump.apache.org:vmgump:05001204122011
Gump E-mail Identifier (unique within run) #1.

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

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

Re: [RELEASE PROCESS] Stability versus usability

[henrib]

Keeping track as it evolves based on feedback;

Goal is to allow easy definition, usage and check of stable APIs.
An annotation and a package naming convention allow the project developer to
clearly state when a class/method/field is not part of the stable contract
despite a public/protected declaration but only of the internal part of the
project.

@internal annotated class/method or *internal* package mean "use this at
your own maintenance cost"; those are not part of the "public" API. They can
be used and extended but are subject to change between versions without
@deprecated annotations.

Those annotations and conventions should allow feeding a clirr report with
the proper information to allow detection of unintended API breakage and may
even allow creating IDE plugins to warn about usage.

--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.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: [RELEASE PROCESS] Stability versus usability

[henrib]

ralph.goers @dslextreme.com wrote
> 
> The part I'm struggling with is that if these are annotations vs just
> javadoc tags then I would expect some kind of either compile time or
> runtime behavior (or both).  It seems that you are proposing javadoc tags
> instead?  If not what behavior would the annotations cause?
> 
I'm not versed enough in Javadoc but I believe annotation carry more
processing "power". The information can remain in the executable and allow
post build analysis. To feed a clirr report, it seems we'd need to
introspect the classes/methods to find those @internal. One could even dream
of a -your favorite IDE here- plugin that warns you when using one of those.
If there is an easy / easier practical solution that could serve the same
purpose, I'm all for it!


--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156415.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: [RELEASE PROCESS] Stability versus usability

[henrib]

Stefan Bodewig wrote
> 
> Would you have known at the point when JEXL 2.0.1 has been released
> which APIs you'd mark up as @stable or @usable?
> 
Yes for most and in doubt, I could have marked them @usable (or @internal
which may be a better term).


--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156394.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: [RELEASE PROCESS] Stability versus usability

[Stefan Bodewig]

On 2011-12-04, henrib wrote:

> When trying to release JEXL 2.1, the API was disrupted and the clirr report
> was outputing lots of clutter.
> As the dev, it became very hard to understand whether the change was
> actually breaking the intended stable API or just some internal methods or
> class.

Would you have known at the point when JEXL 2.0.1 has been released
which APIs you'd mark up as @stable or @usable?

Stefan

-
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

[Ralph Goers]

The part I'm struggling with is that if these are annotations vs just javadoc 
tags then I would expect some kind of either compile time or runtime behavior 
(or both).  It seems that you are proposing javadoc tags instead?  If not what 
behavior would the annotations cause?

Ralph

On Dec 3, 2011, at 5:22 PM, Phil Steitz wrote:

> On 12/2/11 3:45 PM, henrib wrote:
>> It seems to me we have a hard time allowing both stability and usability.
>> Stability of APIs does not contradict usability of the library, at least
>> should not.
>> 
>> Some of us are looking for very long term/stable/high-quality solutions
>> because they need to aggregate lost of components, the stability users.
>> Others are looking for best-of-breed/narrow scope/malleable libraries a with
>> a guaranteed quality, the usability users.
>> Thus the importance of clearly stating in our libraries what is 'stable' and
>> what is 'usable'.
>> The expressiveness in the language itself is not enough to properly describe
>> the contract made regarding each party; i.e. sometimes things have to be
>> public but should not be considered part of the API that follow the
>> major,minor - deprecation.
>> I believe we can come up with a set of agreeable rules to please both
>> "camps" be through some naming convention in packages and annotations.
>> 
>> As an kickstart proposal, may be something as simple as 2 annotations
>> actually could be enough: @stable, @usable.
>> @stable meaning the contract this API represents will not change without
>> being first @deprecated
>> @usable meaning this API is valid for this major version but may change in
>> each minor with no warning
>> We might also use a clear 'internal' sub-package name as a frontier
>> delimiter on the same rule.
>> 
>> Thoughts ?
> 
> I applaud the initiative and creative suggestion above.  I wonder,
> though, what users would make of it.  My first thought as a user
> would be to avoid ever using the "unstable" stuff but I can imagine
> scenarios where I might. 
> 
> In practical terms, it might be hard to decide what to put where. 
> Can you provide some examples based on recent RCs?
> 
> An easy baby step that I could personally get behind - and actually
> need in [math] - is adopting the .internal package name convention
> for classes that need to be public because they are used in multiple
> packages, but which are not intended for use by external
> applications and effectively exempt from version compatibility
> requirements.  That could by itself provide a workaround for a lot
> of these issues.
> 
> Phil
>> Best regards,
>> Henri
>> 
>> --
>> View this message in context: 
>> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.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
> 


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