date:20111211

On 11 December 2011 10:04, henrib hen...@apache.org wrote:
 +1

 The tag is actually
 https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_1-RC3/

Oops, sorry.
 .
 There is one minor error in the Javadoc (interpreter visit FloatLiteral /
 IntegerLiteral) but since these are deprecated, it has no importance.

Not sure I understand what the error is here - I'd like to fix it for
any future releases, but can't work out what's wrong.

 Otherwise, everything looks good to me.

 Thanks Sebb for your hardwork.

Thanks!


 --
 View this message in context: 
 http://apache-commons.680414.n4.nabble.com/VOTE-Release-JEXL-2-1-based-on-RC3-tp4174001p4182455.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: [Sanselan] release plan?

On 9 December 2011 13:53, sebb seb...@gmail.com wrote:
 On 9 December 2011 13:52, Gary Gregory garydgreg...@gmail.com wrote:
 On Fri, Dec 9, 2011 at 8:51 AM, Gary Gregory garydgreg...@gmail.com wrote:

 On Fri, Dec 9, 2011 at 8:45 AM, sebb seb...@gmail.com wrote:

 On 9 December 2011 12:10, Damjan Jovanovic damjan@gmail.com wrote:
  Hi
 
  Yes, it's time for a release. All tests now pass, and most of the
 serious
  issues are now fixed.

 The tests are very noisy at present - there is a lot of output to
 standard out, which makes it quite tricky to follow the progress of
 the tests.

 The debug output should be off by default; it might however be useful
 to make this switchable, rather than deleting it.

 Probably sufficient to do this per test class as a static boolean flag.
 If a test case fails, one will need to go into the code anyway, so
 probably not necessary to make the output externally switchable.

 Agreed?

  However I did promise a few people their patches would get attention, so
  first I would like to review and apply the TIFF performance enhancement
  patches by Gary Lucas (SANSELAN-56 to 58), and the TIFF G.3 and G.4
  compression patches (SANSELAN-48). Then after that, which is hopefully
  early next week, I'll start the release process.
 
  Regards
  Damjan
 
  On Fri, Dec 9, 2011 at 1:20 PM, Gary Gregory garydgreg...@gmail.com
 wrote:
 
  Hi all,
 
  I've a lot of commit activity here recently which is quite welcome.
  What are thoughts on releasing? Can anyone comment on the state of the
  component?


 +1. Or, the tests can use log4j... which seems more civilized and reading
 and editing code to enable debug output.


 Or JUL for that matter.

 Should have read the code first - there's actually a Debug class that
 handles all the output, so it's easy to fix this.

Done.

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

Re: [VOTE] Release Apache Commons Gigester 3.2 based on RC2

On Sat, Dec 10, 2011 at 4:18 PM, Simone Tripodi
simonetrip...@apache.org wrote:
 [X] +1 release it

Checked sigs/checksums, looked at the site, opened stuff et al worked
all very well for me.
License is included in LICENSE.txt, NOTICE looks correct (as explained
by Sebbs link).

Just one minor thing, which is not a blocker imho: the API docs do show

Copyright © 2001-2011 The Apache Software Foundation. All Rights Reserved.

but it should show - to my understanding - this additional text:

Apache Commons, Apache Apache Commons Digester, Apache, the Apache
feather logo, and the Apache Commons project logos are trademarks of
The Apache Software Foundation. All other marks mentioned may be
trademarks or registered trademarks of their respective owners.

I think this can be done with the next release, as the website looks perfect.

Cheers
Christian


-- 
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] Release Apache Commons Gigester 3.2 based on RC2

This is my explicit +1

Thanks a lot for reviewing Christian!!!
have a nice WE,
-Simo

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



On Sun, Dec 11, 2011 at 12:24 PM, Christian Grobmeier
grobme...@gmail.com wrote:
 On Sat, Dec 10, 2011 at 4:18 PM, Simone Tripodi
 simonetrip...@apache.org wrote:
 [X] +1 release it

 Checked sigs/checksums, looked at the site, opened stuff et al worked
 all very well for me.
 License is included in LICENSE.txt, NOTICE looks correct (as explained
 by Sebbs link).

 Just one minor thing, which is not a blocker imho: the API docs do show

 Copyright © 2001-2011 The Apache Software Foundation. All Rights Reserved.

 but it should show - to my understanding - this additional text:

 Apache Commons, Apache Apache Commons Digester, Apache, the Apache
 feather logo, and the Apache Commons project logos are trademarks of
 The Apache Software Foundation. All other marks mentioned may be
 trademarks or registered trademarks of their respective owners.

 I think this can be done with the next release, as the website looks perfect.

 Cheers
 Christian


 --
 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


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

Re: [VOTE] Release Apache Commons Gigester 3.2 based on RC2

On 11 December 2011 11:24, Christian Grobmeier grobme...@gmail.com wrote:
 On Sat, Dec 10, 2011 at 4:18 PM, Simone Tripodi
 simonetrip...@apache.org wrote:
 [X] +1 release it

 Checked sigs/checksums, looked at the site, opened stuff et al worked
 all very well for me.
 License is included in LICENSE.txt, NOTICE looks correct (as explained
 by Sebbs link).

 Just one minor thing, which is not a blocker imho: the API docs do show

 Copyright © 2001-2011 The Apache Software Foundation. All Rights Reserved.

 but it should show - to my understanding - this additional text:

 Apache Commons, Apache Apache Commons Digester, Apache, the Apache
 feather logo, and the Apache Commons project logos are trademarks of
 The Apache Software Foundation. All other marks mentioned may be
 trademarks or registered trademarks of their respective owners.

The API docs don't actually include the project or feather logos, so
that part at least is not necessary.

As far as I'm aware, this is the first time anyone has suggested that
Javadocs should have the same footer as the rest of the site.
Maven-generated reports (Clirr etc) automatically use the same footer,
but they are embedded in the site LF.

 I think this can be done with the next release, as the website looks perfect.

Yes; meanwhile perhaps the requirements could be clarified with
Branding, because I suspect most projects don't customise their
Javadocs in that way.

If it is necessary, hopefully it can be added to Commons Parent.

 Cheers
 Christian


 --
 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


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

Re: [VOTE] Release Apache Commons Gigester 3.2 based on RC2


 If it is necessary, hopefully it can be added to Commons Parent.
+1 javadoc plugin allows custom footers[1], should not be a big deal.

Waiting for your +1, Seb ;)
best,
-Simo

[1] 
http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#footer

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: [VOTE] Release JEXL 2.1 based on RC3

Just curious - jexl is releasing tests? Why that?
commons-jexl-2.1-tests.jar

https://repository.apache.org/content/repositories/orgapachecommons-298/org/apache/commons/commons-jexl/2.1/

On Thu, Dec 8, 2011 at 8:44 PM, sebb seb...@gmail.com wrote:
Further to the earlier cancelled RC1 vote, here is an updated release
candidate.

The main change since RC1 is that all binary incompatibilities have
been resolved.

Clirr still reports errors for interfaces that have additional
methods, but these are false positives, as the changes only affect
source compatibility.

Compatibility with previous releases
==
Version 2.1 is binary compatible with 2.0.1.

However it is not source compatible.
New methods have been added to the org.apache.commons.jexl2.Script and
org.apache.commons.jexl2.JexlInfo interfaces.
Any source code that implements these interfaces will need to be updated.

What's new in 2.1:
==
* A more thorough arithmetic (JexlArithmetic) that allows fine control
over decimals (scale and precision), a
new syntax for numeric literals (OGNL inspired Big and Huge
notations) and a better type handling keeping the most
appropriate representation in casual operations.
* The introduction of script variables and parameters that reduce
context dependencies and methods; this allows to
perform checks after script creation (light static checking hints).
Plus the ability to call script from scripts.
* A sandoxing feature to restrict and rename what JEXL can access from
the environment allowing tighter control over security.
* Extensions to UnifiedJEXL that allow the creation of templates.

New features in 2.1:

* JEXL-114: Allow scripts to create local variables // Add return keyword
* JEXL-113: Add functions to extract which variables, parameters
and local variables are used to evaluate a script
* JEXL-118: Provide an IN operator
* JEXL-115: Add support for asynchronous script execution and cancellation
* JEXL-116: Add control over classes, methods, constructors and
properties allowed in scripts
* JEXL-120: Add simple template features
* JEXL-119: Allow indexed properties container resolution in expressions

Tag:

https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_1_RC3/

Site:

http://people.apache.org/~sebb/jexl-2.1-RC3

Binaries:

https://repository.apache.org/content/repositories/orgapachecommons-298/org/apache/commons/commons-jexl/

This vote will be open for at least 72 hours, closing no sooner than:
20:00PM GMT, Dec 11th.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

-
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] Release JEXL 2.1 based on RC3

On 11 December 2011 12:42, Christian Grobmeier grobme...@gmail.com wrote:
Just curious - jexl is releasing tests? Why that?
commons-jexl-2.1-tests.jar

It was decided a while ago to add these to make it easier to check
binary compatibility between versions.

Simpler to create the test jars at the same time, rather than try to
recreate them later (in theory that is possible from the tag, but it's
tedious).

https://repository.apache.org/content/repositories/orgapachecommons-298/org/apache/commons/commons-jexl/2.1/

On Thu, Dec 8, 2011 at 8:44 PM, sebb seb...@gmail.com wrote:
Further to the earlier cancelled RC1 vote, here is an updated release
candidate.

The main change since RC1 is that all binary incompatibilities have
been resolved.

Clirr still reports errors for interfaces that have additional
methods, but these are false positives, as the changes only affect
source compatibility.

Compatibility with previous releases
==
Version 2.1 is binary compatible with 2.0.1.

New features in 2.1:

* JEXL-114: Allow scripts to create local variables // Add return keyword
* JEXL-113: Add functions to extract which variables, parameters
and local variables are used to evaluate a script
* JEXL-118: Provide an IN operator
* JEXL-115: Add support for asynchronous script execution and
cancellation
* JEXL-116: Add control over classes, methods, constructors and
properties allowed in scripts
* JEXL-120: Add simple template features
* JEXL-119: Allow indexed properties container resolution in expressions

Tag:

https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_1_RC3/

Site:

http://people.apache.org/~sebb/jexl-2.1-RC3

Binaries:

https://repository.apache.org/content/repositories/orgapachecommons-298/org/apache/commons/commons-jexl/

This vote will be open for at least 72 hours, closing no sooner than:
20:00PM GMT, Dec 11th.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

-
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] Release JEXL 2.1 based on RC3

+1 looks good to me
have checked sigs, opened the stuff, looked at license, notice etc.
API docs do contain not all of the copyright statements as on the
website (as discussed in the digester vote).

Cheers,
Christian

On Thu, Dec 8, 2011 at 8:44 PM, sebb seb...@gmail.com wrote:
Further to the earlier cancelled RC1 vote, here is an updated release
candidate.

The main change since RC1 is that all binary incompatibilities have
been resolved.

Clirr still reports errors for interfaces that have additional
methods, but these are false positives, as the changes only affect
source compatibility.

Compatibility with previous releases
==
Version 2.1 is binary compatible with 2.0.1.

New features in 2.1:

Tag:

https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_1_RC3/

Site:

http://people.apache.org/~sebb/jexl-2.1-RC3

Binaries:

https://repository.apache.org/content/repositories/orgapachecommons-298/org/apache/commons/commons-jexl/

This vote will be open for at least 72 hours, closing no sooner than:
20:00PM GMT, Dec 11th.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

-
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] Release pool 1.5.7 based on RC3

On Sat, Dec 10, 2011 at 9:58 PM, Phil Steitz phil.ste...@gmail.com wrote:





 On Dec 10, 2011, at 6:31 PM, sebb seb...@gmail.com wrote:

  On 11 December 2011 00:29, Phil Steitz phil.ste...@gmail.com wrote:
  This is a patch release, including a couple of bug fixes.
 
  The release artifacts are here:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/
 
  Release notes:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/RELEASE-NOTES.txt
 
  Maven distribution:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/maven
 
  There's no test jar - I thought we were going to try providing those?
  I think that is one of the added features in the CP 22 release profile.

 This is a patch release identical to 1.5.6  other than the two bug fixes
 in the release notes.  I see no reason to add artifacts.

 
  Site:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/docs
  (Links, including an added link to the released API docs, will be
  updated post release)
 
  It would be nice to have a Clirr report for the differences from 1.5.6
  as well as from 1.5.
  Dunno if that is possible

 There were no API changes.

 
  Tag:
  http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_7_RC3
 
  Uses old Commons Parent version.

 That is intentional.  Avoids some issues generating artifacts.  Again,
 this is just a patch release on a maintenance branch. No reason to mess
 with a working build.


working, yes on Maven 2, but not on Maven 3:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site)
on project commons
to parse configuration of mojo
org.codehaus.mojo:findbugs-maven-plugin:1.2:findbugs for parameter
localRepository: Abstract
.artifact.repository.DefaultArtifactRepository' cannot be instantiated -
[Help 1]

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.6.0_29, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_29\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
C:\temp\commons-pool-1.5.7-srcset java_home=%java_7_home%

It's nice to touch as little as possible in production code for a
maintenance release, but the build should be OK to move forward IMO.
Especially when you cannot even build on M3. I also like the consistency of
a current releases using the current parent POM.

+0

Gary



 
  Many source files use $Date:$ SVN markers; these make it awkward to
  compare against the SVN tag
 
  Votes, please.  This vote will close in 72 hours, 14-DEC-01:00 GMT.
 
  [ ] +1 I support this release
  [X] +0 OK, but...
  [ ] -0 Not happy about this because...
  [ ] -1 I oppose this release
 
  Thanks!
 
  Phil
 
  -
  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




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

Re: [VOTE] Release Apache Commons Gigester 3.2 based on RC2

+1

I'm not crazy happy about the one Clirr error but it seems to have been
explained away satisfactorily.

Non-blockers:

- TM in logo is too big IMO.
- Some easy PMDs to fix:
  - Overriding method merely calls super
  - Avoid unused private methods such as 'npeSafeCast(Object)'.

Tested m3 clean site with:

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.7.0_01*, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_01\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows

Also, no build test failures m3 clean site:

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.6.0_29*, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_29\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows

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

Gary

On Sat, Dec 10, 2011 at 10:18 AM, Simone Tripodi
simonetrip...@apache.orgwrote:

 Hi all guys,I'm writing to call for a vote to release apache
 commons-digester-3.2 based on RC2.
 Please take in consideration that: * broken 3.2 links will be fixed
 once the site will be deployed; * there is a Clirr violation, but:
 1) target class is used for internal use only - there is no way users
 can reuse it;   2) arguments type are still assignable.
 The vote will stay open for at least 72 hours and closes approximately
 on Tuesday 13th, at 3:20pm CET.
 Many thanks in advance for reviewing, have a nice day!All the best,-Simo
 Release notes:

 http://people.apache.org/builds/commons/digester/3.2/RC2/RELEASE-NOTES.txt
 Tag:

 https://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER3_3_2_RC2/
 Site:
  http://people.apache.org/builds/commons/digester/3.2/RC2/site/
 Binaries:
  http://people.apache.org/builds/commons/digester/3.2/RC2/binaries/
 Maven Artifacts (staged on Nexus)

 https://repository.apache.org/content/repositories/orgapachecommons-310/org/apache/commons/commons-digester3/3.2/
 [ ] +1 release it[ ] +0 go ahead I don't care[ ] -1 no, do not release
 it because... (please explain why)

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

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




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

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

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

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


Full details are available at:

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

That said, some information snippets are provided here.

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



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html
Work Name: build_apache-commons_commons-exec-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 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.024 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 8014 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.889 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 11 14:30:44 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 05001211122011, vmgump.apache.org:vmgump:05001211122011
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: [VOTE] Release JEXL 2.1 based on RC3

Note: There is an alarming number of PMD issues reported. A lot of these
look like they are in generated code, but not all. Has this been mentioned?

Non-blockers:

- Some Javadoc checkstyle errors.
- Findbugs oddities.

Tested m3 'clean site' with:

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

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.6.0_29*, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_29\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows

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.7.0_01*, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_01\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows

Gary

On Thu, Dec 8, 2011 at 2:44 PM, sebb seb...@gmail.com wrote:

Further to the earlier cancelled RC1 vote, here is an updated release
candidate.

The main change since RC1 is that all binary incompatibilities have
been resolved.

Clirr still reports errors for interfaces that have additional
methods, but these are false positives, as the changes only affect
source compatibility.

Compatibility with previous releases
==
Version 2.1 is binary compatible with 2.0.1.

New features in 2.1:

* JEXL-114: Allow scripts to create local variables // Add return
keyword
* JEXL-113: Add functions to extract which variables, parameters
and local variables are used to evaluate a script
* JEXL-118: Provide an IN operator
* JEXL-115: Add support for asynchronous script execution and
cancellation
* JEXL-116: Add control over classes, methods, constructors and
properties allowed in scripts
* JEXL-120: Add simple template features
* JEXL-119: Allow indexed properties container resolution in
expressions

Tag:

https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_1_RC3/

Site:

http://people.apache.org/~sebb/jexl-2.1-RC3

Binaries:

https://repository.apache.org/content/repositories/orgapachecommons-298/org/apache/commons/commons-jexl/

This vote will be open for at least 72 hours, closing no sooner than:
20:00PM GMT, Dec 11th.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

-
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://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Release JEXL 2.1 based on RC3

I'm not worried about source compatibility issues, I join Gary on
checkstyle/PMD observations

Simo

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

On Sun, Dec 11, 2011 at 5:32 PM, Gary Gregory garydgreg...@gmail.com wrote:
+1

Note: There is an alarming number of PMD issues reported. A lot of these
look like they are in generated code, but not all. Has this been mentioned?

Non-blockers:

- Some Javadoc checkstyle errors.
- Findbugs oddities.

Tested m3 'clean site' with:

Gary

On Thu, Dec 8, 2011 at 2:44 PM, sebb seb...@gmail.com wrote:

Further to the earlier cancelled RC1 vote, here is an updated release
candidate.

The main change since RC1 is that all binary incompatibilities have
been resolved.

Clirr still reports errors for interfaces that have additional
methods, but these are false positives, as the changes only affect
source compatibility.

Compatibility with previous releases
==
Version 2.1 is binary compatible with 2.0.1.

New features in 2.1:

* JEXL-114: Allow scripts to create local variables // Add return
keyword
* JEXL-113: Add functions to extract which variables, parameters
and local variables are used to evaluate a script
* JEXL-118: Provide an IN operator
* JEXL-115: Add support for asynchronous script execution and
cancellation
* JEXL-116: Add control over classes, methods, constructors and
properties allowed in scripts
* JEXL-120: Add simple template features
* JEXL-119: Allow indexed properties container resolution in
expressions

Tag:

https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_1_RC3/

Site:

http://people.apache.org/~sebb/jexl-2.1-RC3

Binaries:

https://repository.apache.org/content/repositories/orgapachecommons-298/org/apache/commons/commons-jexl/

This vote will be open for at least 72 hours, closing no sooner than:
20:00PM GMT, Dec 11th.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

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

Re: [VOTE] Release Apache Commons Gigester 3.2 based on RC2

2011-12-11 Thread Oliver Heger


+1

Build works fine with Java 1.5 on Windows 7. Artifacts and site look good.

One minor nit: In the release notes the following recommended 
dependencies are listed:

The Recommended Dependency Set for Digester 3.0 is:
   Digester 3.1 + Logging 1.1.1 + BeanUtils 1.8.3

This is a bit confusing due to the different Digester version numbers. 
Also, the site lists CGLib as additional dependency.


Oliver

Am 10.12.2011 16:18, schrieb Simone Tripodi:

Hi all guys,I'm writing to call for a vote to release apache
commons-digester-3.2 based on RC2.
Please take in consideration that: * broken 3.2 links will be fixed
once the site will be deployed; * there is a Clirr violation, but:
1) target class is used for internal use only - there is no way users
can reuse it;   2) arguments type are still assignable.
The vote will stay open for at least 72 hours and closes approximately
on Tuesday 13th, at 3:20pm CET.
Many thanks in advance for reviewing, have a nice day!All the best,-Simo
Release notes:
  http://people.apache.org/builds/commons/digester/3.2/RC2/RELEASE-NOTES.txt
Tag:
  
https://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER3_3_2_RC2/
Site:
  http://people.apache.org/builds/commons/digester/3.2/RC2/site/
Binaries:
  http://people.apache.org/builds/commons/digester/3.2/RC2/binaries/
Maven Artifacts (staged on Nexus)
  
https://repository.apache.org/content/repositories/orgapachecommons-310/org/apache/commons/commons-digester3/3.2/
[ ] +1 release it[ ] +0 go ahead I don't care[ ] -1 no, do not release
it because... (please explain why)

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

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




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

Re: [VOTE] Release pool 1.5.7 based on RC3

2011-12-11 Thread Phil Steitz

On 12/11/11 6:28 AM, Gary Gregory wrote:
 On Sat, Dec 10, 2011 at 9:58 PM, Phil Steitz phil.ste...@gmail.com wrote:




 On Dec 10, 2011, at 6:31 PM, sebb seb...@gmail.com wrote:

 On 11 December 2011 00:29, Phil Steitz phil.ste...@gmail.com wrote:
 This is a patch release, including a couple of bug fixes.

 The release artifacts are here:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/

 Release notes:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/RELEASE-NOTES.txt

 Maven distribution:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/maven
 There's no test jar - I thought we were going to try providing those?
 I think that is one of the added features in the CP 22 release profile.
 This is a patch release identical to 1.5.6  other than the two bug fixes
 in the release notes.  I see no reason to add artifacts.

 Site:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/docs
 (Links, including an added link to the released API docs, will be
 updated post release)
 It would be nice to have a Clirr report for the differences from 1.5.6
 as well as from 1.5.
 Dunno if that is possible
 There were no API changes.

 Tag:
 http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_7_RC3
 Uses old Commons Parent version.
 That is intentional.  Avoids some issues generating artifacts.  Again,
 this is just a patch release on a maintenance branch. No reason to mess
 with a working build.

 working, yes on Maven 2, but not on Maven 3:

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site)
 on project commons
 to parse configuration of mojo
 org.codehaus.mojo:findbugs-maven-plugin:1.2:findbugs for parameter
 localRepository: Abstract
 .artifact.repository.DefaultArtifactRepository' cannot be instantiated -
 [Help 1]

 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.6.0_29, vendor: Sun Microsystems Inc.
 Java home: C:\Program Files\Java\jdk1.6.0_29\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: windows 7, version: 6.1, arch: amd64, family: windows
 C:\temp\commons-pool-1.5.7-srcset java_home=%java_7_home%

 It's nice to touch as little as possible in production code for a
 maintenance release, but the build should be OK to move forward IMO.
 Especially when you cannot even build on M3. I also like the consistency of
 a current releases using the current parent POM.

No.  Maven and maven plugins make incompatible changes regularly. 
We can't possibly expect our releases to work with future
incompatible changes in maven or maven plugins.

I see no reason to reengineer the build between 1.5.6 and 1.5.7 on a
maintenance branch.  Is there anything wrong with the release
artifacts or code? 

Phil

 +0

 Gary



 Many source files use $Date:$ SVN markers; these make it awkward to
 compare against the SVN tag

 Votes, please.  This vote will close in 72 hours, 14-DEC-01:00 GMT.

 [ ] +1 I support this release
 [X] +0 OK, but...
 [ ] -0 Not happy about this because...
 [ ] -1 I oppose this release

 Thanks!

 Phil

 -
 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





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

Re: [VOTE] Release Apache Commons Gigester 3.2 based on RC2

2011-12-11 Thread Paul Benedict

Any product called the Gigester gets my +1 vote!

On Sun, Dec 11, 2011 at 10:56 AM, Oliver Heger oliver.he...@oliver-heger.de
 wrote:

 +1

 Build works fine with Java 1.5 on Windows 7. Artifacts and site look good.

 One minor nit: In the release notes the following recommended dependencies
 are listed:
 The Recommended Dependency Set for Digester 3.0 is:
   Digester 3.1 + Logging 1.1.1 + BeanUtils 1.8.3

 This is a bit confusing due to the different Digester version numbers.
 Also, the site lists CGLib as additional dependency.

 Oliver

 Am 10.12.2011 16:18, schrieb Simone Tripodi:

  Hi all guys,I'm writing to call for a vote to release apache
 commons-digester-3.2 based on RC2.
 Please take in consideration that: * broken 3.2 links will be fixed
 once the site will be deployed; * there is a Clirr violation, but:
 1) target class is used for internal use only - there is no way users
 can reuse it;   2) arguments type are still assignable.
 The vote will stay open for at least 72 hours and closes approximately
 on Tuesday 13th, at 3:20pm CET.
 Many thanks in advance for reviewing, have a nice day!All the best,-Simo
 Release notes:
  http://people.apache.org/**builds/commons/digester/3.2/**
 RC2/RELEASE-NOTES.txthttp://people.apache.org/builds/commons/digester/3.2/RC2/RELEASE-NOTES.txt
 Tag:
  https://svn.apache.org/repos/**asf/commons/proper/digester/**
 tags/DIGESTER3_3_2_RC2/https://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER3_3_2_RC2/
 Site:
  
 http://people.apache.org/**builds/commons/digester/3.2/**RC2/site/http://people.apache.org/builds/commons/digester/3.2/RC2/site/
 Binaries:
  
 http://people.apache.org/**builds/commons/digester/3.2/**RC2/binaries/http://people.apache.org/builds/commons/digester/3.2/RC2/binaries/
 Maven Artifacts (staged on Nexus)
  https://repository.apache.org/**content/repositories/**
 orgapachecommons-310/org/**apache/commons/commons-**digester3/3.2/https://repository.apache.org/content/repositories/orgapachecommons-310/org/apache/commons/commons-digester3/3.2/
 [ ] +1 release it[ ] +0 go ahead I don't care[ ] -1 no, do not release
 it because... (please explain why)

 http://people.apache.org/~**simonetripodi/http://people.apache.org/%7Esimonetripodi/
 http://simonetripodi.**livejournal.com/http://simonetripodi.livejournal.com/
 http://twitter.com/**simonetripodi http://twitter.com/simonetripodi
 http://www.99soft.org/

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



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

Re: [VOTE] Release pool 1.5.7 based on RC3

2011-12-11 Thread Phil Steitz

Here is my +1

Could use a couple of more so the bug fixes can go out and we can
proceed to a patch release for [dbcp] 1.3/1.4.

Phil

On 12/10/11 5:29 PM, Phil Steitz wrote:
 This is a patch release, including a couple of bug fixes. 

 The release artifacts are here:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/

 Release notes:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/RELEASE-NOTES.txt

 Maven distribution:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/maven

 Site:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/docs
 (Links, including an added link to the released API docs, will be
 updated post release)

 Tag:
 http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_7_RC3

 Votes, please.  This vote will close in 72 hours, 14-DEC-01:00 GMT.

 [ ] +1 I support this release
 [ ] +0 OK, but...
 [ ] -0 Not happy about this because...
 [ ] -1 I oppose this release

 Thanks!

 Phil


-
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 DbUtils - Default Maven 2 Build Definition (Java 1.5)

2011-12-11 Thread Continuum@vmbuild

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=15727projectId=74

Build statistics:
  State: Failed
  Previous State: Failed
  Started at: Sun 11 Dec 2011 17:41:41 +
  Finished at: Sun 11 Dec 2011 17:41:57 +
  Total time: 15s
  Build Trigger: Schedule
  Build Number: 57
  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: wspeirs @ Sun 11 Dec 2011 16:40:06 +
Comment: - Changed Java version to 1.6
- Removed clirr and compiler plugin (inherited from CP 22)
- Noted changes in changes.xml
Files changed:
  /commons/proper/dbutils/trunk/pom.xml ( 1213019 )
  /commons/proper/dbutils/trunk/src/changes/changes.xml ( 1213019 )


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: 0
Failures: 0
Errors: 0
Total time: 0.0





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

Re: [VOTE] Release pool 1.5.7 based on RC3

On Sun, Dec 11, 2011 at 12:28 PM, Phil Steitz phil.ste...@gmail.com wrote:

 On 12/11/11 6:28 AM, Gary Gregory wrote:
  On Sat, Dec 10, 2011 at 9:58 PM, Phil Steitz phil.ste...@gmail.com
 wrote:
 
 
 
 
  On Dec 10, 2011, at 6:31 PM, sebb seb...@gmail.com wrote:
 
  On 11 December 2011 00:29, Phil Steitz phil.ste...@gmail.com wrote:
  This is a patch release, including a couple of bug fixes.
 
  The release artifacts are here:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/
 
  Release notes:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/RELEASE-NOTES.txt
 
  Maven distribution:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/maven
  There's no test jar - I thought we were going to try providing those?
  I think that is one of the added features in the CP 22 release profile.
  This is a patch release identical to 1.5.6  other than the two bug fixes
  in the release notes.  I see no reason to add artifacts.
 
  Site:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/docs
  (Links, including an added link to the released API docs, will be
  updated post release)
  It would be nice to have a Clirr report for the differences from 1.5.6
  as well as from 1.5.
  Dunno if that is possible
  There were no API changes.
 
  Tag:
 
 http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_7_RC3
  Uses old Commons Parent version.
  That is intentional.  Avoids some issues generating artifacts.  Again,
  this is just a patch release on a maintenance branch. No reason to mess
  with a working build.
 
  working, yes on Maven 2, but not on Maven 3:
 
  [ERROR] Failed to execute goal
  org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site)
  on project commons
  to parse configuration of mojo
  org.codehaus.mojo:findbugs-maven-plugin:1.2:findbugs for parameter
  localRepository: Abstract
  .artifact.repository.DefaultArtifactRepository' cannot be instantiated -
  [Help 1]
 
  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.6.0_29, vendor: Sun Microsystems Inc.
  Java home: C:\Program Files\Java\jdk1.6.0_29\jre
  Default locale: en_US, platform encoding: Cp1252
  OS name: windows 7, version: 6.1, arch: amd64, family: windows
  C:\temp\commons-pool-1.5.7-srcset java_home=%java_7_home%
 
  It's nice to touch as little as possible in production code for a
  maintenance release, but the build should be OK to move forward IMO.
  Especially when you cannot even build on M3. I also like the consistency
 of
  a current releases using the current parent POM.

 No.  Maven and maven plugins make incompatible changes regularly.
 We can't possibly expect our releases to work with future
 incompatible changes in maven or maven plugins.

 I see no reason to reengineer the build between 1.5.6 and 1.5.7 on a
 maintenance branch.  Is there anything wrong with the release
 artifacts or code?


Nope, the production bits are working.

I do not look at this as a right or wrong. I just ask myself Is this the
best I can do? For me, personally, that would be no. Different strokes
for different folks :)

Gary


 Phil
 
  +0
 
  Gary
 
 
 
  Many source files use $Date:$ SVN markers; these make it awkward to
  compare against the SVN tag
 
  Votes, please.  This vote will close in 72 hours, 14-DEC-01:00 GMT.
 
  [ ] +1 I support this release
  [X] +0 OK, but...
  [ ] -0 Not happy about this because...
  [ ] -1 I oppose this release
 
  Thanks!
 
  Phil
 
  -
  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
 
 
 


 -
 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://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Release Apache Commons Gigester 3.2 based on RC2

Hello!!!

@Oliver: thanks for reviewing! can you tell me please where did you
notice about 3.0 in the release note? I was sure I fixed it on both
/trunk and RC, see[1]... Thanks!!

@Paul: looks like the 'Gigester' name is getting more success than the
Digester itself :D

All the best,
-Simo

[1] http://people.apache.org/builds/commons/digester/3.2/RC2/RELEASE-NOTES.txt


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



On Sun, Dec 11, 2011 at 6:30 PM, Paul Benedict pbened...@apache.org wrote:
 Any product called the Gigester gets my +1 vote!

 On Sun, Dec 11, 2011 at 10:56 AM, Oliver Heger oliver.he...@oliver-heger.de
 wrote:

 +1

 Build works fine with Java 1.5 on Windows 7. Artifacts and site look good.

 One minor nit: In the release notes the following recommended dependencies
 are listed:
 The Recommended Dependency Set for Digester 3.0 is:
   Digester 3.1 + Logging 1.1.1 + BeanUtils 1.8.3

 This is a bit confusing due to the different Digester version numbers.
 Also, the site lists CGLib as additional dependency.

 Oliver

 Am 10.12.2011 16:18, schrieb Simone Tripodi:

  Hi all guys,I'm writing to call for a vote to release apache
 commons-digester-3.2 based on RC2.
 Please take in consideration that: * broken 3.2 links will be fixed
 once the site will be deployed; * there is a Clirr violation, but:
 1) target class is used for internal use only - there is no way users
 can reuse it;   2) arguments type are still assignable.
 The vote will stay open for at least 72 hours and closes approximately
 on Tuesday 13th, at 3:20pm CET.
 Many thanks in advance for reviewing, have a nice day!All the best,-Simo
 Release notes:
  http://people.apache.org/**builds/commons/digester/3.2/**
 RC2/RELEASE-NOTES.txthttp://people.apache.org/builds/commons/digester/3.2/RC2/RELEASE-NOTES.txt
 Tag:
  https://svn.apache.org/repos/**asf/commons/proper/digester/**
 tags/DIGESTER3_3_2_RC2/https://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER3_3_2_RC2/
 Site:
  http://people.apache.org/**builds/commons/digester/3.2/**RC2/site/http://people.apache.org/builds/commons/digester/3.2/RC2/site/
 Binaries:
  http://people.apache.org/**builds/commons/digester/3.2/**RC2/binaries/http://people.apache.org/builds/commons/digester/3.2/RC2/binaries/
 Maven Artifacts (staged on Nexus)
  https://repository.apache.org/**content/repositories/**
 orgapachecommons-310/org/**apache/commons/commons-**digester3/3.2/https://repository.apache.org/content/repositories/orgapachecommons-310/org/apache/commons/commons-digester3/3.2/
 [ ] +1 release it[ ] +0 go ahead I don't care[ ] -1 no, do not release
 it because... (please explain why)

 http://people.apache.org/~**simonetripodi/http://people.apache.org/%7Esimonetripodi/
 http://simonetripodi.**livejournal.com/http://simonetripodi.livejournal.com/
 http://twitter.com/**simonetripodi http://twitter.com/simonetripodi
 http://www.99soft.org/

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



 --**--**-
 To unsubscribe, e-mail: 
 dev-unsubscribe@commons.**apache.orgdev-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] Release pool 1.5.7 based on RC3

+1

checked sigs, site, opened all that stuff, runned test... looks all ok so far.
Not providing a test jar is ok for me (or is this a Commons poilicy??
have missed it somehow) as I can run the tests from the provided src
package.

On Garys comments with M2/M3:
Tests can be run from the source package, which I have with Maven
3.0.3 (and with success :-))

I think building site is not so important as running tests. For
building the site with M3 one must adjust the pom file - I am not sure
if it would run with M2 then. Anyway, I think it is more the question
if whole Commons should use one build tool because it is much easier
for the user to just have one thing installed.

Cheers
Christian



On Sun, Dec 11, 2011 at 1:29 AM, Phil Steitz phil.ste...@gmail.com wrote:
 This is a patch release, including a couple of bug fixes.

 The release artifacts are here:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/

 Release notes:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/RELEASE-NOTES.txt

 Maven distribution:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/maven

 Site:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/docs
 (Links, including an added link to the released API docs, will be
 updated post release)

 Tag:
 http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_7_RC3

 Votes, please.  This vote will close in 72 hours, 14-DEC-01:00 GMT.

 [ ] +1 I support this release
 [ ] +0 OK, but...
 [ ] -0 Not happy about this because...
 [ ] -1 I oppose this release

 Thanks!

 Phil

 -
 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] Release pool 1.5.7 based on RC3

On Sun, Dec 11, 2011 at 12:56 PM, Christian Grobmeier
grobme...@gmail.comwrote:

 +1

 checked sigs, site, opened all that stuff, runned test... looks all ok so
 far.
 Not providing a test jar is ok for me (or is this a Commons poilicy??
 have missed it somehow) as I can run the tests from the provided src
 package.

 On Garys comments with M2/M3:
 Tests can be run from the source package, which I have with Maven
 3.0.3 (and with success :-))

 I think building site is not so important as running tests. For
 building the site with M3 one must adjust the pom file - I am not sure
 if it would run with M2 then.


FYI: Commons parent makes sure that M2 and M3 works, if you use a recent CP
version that is.

Gary


 Anyway, I think it is more the question
 if whole Commons should use one build tool because it is much easier
 for the user to just have one thing installed.

 Cheers
 Christian



 On Sun, Dec 11, 2011 at 1:29 AM, Phil Steitz phil.ste...@gmail.com
 wrote:
  This is a patch release, including a couple of bug fixes.
 
  The release artifacts are here:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/
 
  Release notes:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/RELEASE-NOTES.txt
 
  Maven distribution:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/maven
 
  Site:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/docs
  (Links, including an added link to the released API docs, will be
  updated post release)
 
  Tag:
  http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_7_RC3
 
  Votes, please.  This vote will close in 72 hours, 14-DEC-01:00 GMT.
 
  [ ] +1 I support this release
  [ ] +0 OK, but...
  [ ] -0 Not happy about this because...
  [ ] -1 I oppose this release
 
  Thanks!
 
  Phil
 
  -
  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




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

Re: [VOTE] Release pool 1.5.7 based on RC3

On Sun, Dec 11, 2011 at 7:18 PM, Gary Gregory garydgreg...@gmail.com wrote:
 On Sun, Dec 11, 2011 at 12:56 PM, Christian Grobmeier
 grobme...@gmail.comwrote:

 +1

 checked sigs, site, opened all that stuff, runned test... looks all ok so
 far.
 Not providing a test jar is ok for me (or is this a Commons poilicy??
 have missed it somehow) as I can run the tests from the provided src
 package.

 On Garys comments with M2/M3:
 Tests can be run from the source package, which I have with Maven
 3.0.3 (and with success :-))

 I think building site is not so important as running tests. For
 building the site with M3 one must adjust the pom file - I am not sure
 if it would run with M2 then.


 FYI: Commons parent makes sure that M2 and M3 works, if you use a recent CP
 version that is.

Thanks for the hint, didn't know it. Actually now I think components
should always upgrade to the recent cp before a new release.
I still give +1, but would love to see pool upgrading to recent cp
with the next release, if possible.

Cheers
Christian


 Gary


 Anyway, I think it is more the question
 if whole Commons should use one build tool because it is much easier
 for the user to just have one thing installed.

 Cheers
 Christian



 On Sun, Dec 11, 2011 at 1:29 AM, Phil Steitz phil.ste...@gmail.com
 wrote:
  This is a patch release, including a couple of bug fixes.
 
  The release artifacts are here:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/
 
  Release notes:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/RELEASE-NOTES.txt
 
  Maven distribution:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/maven
 
  Site:
  http://people.apache.org/~psteitz/pool-1.5.7-rc3/docs
  (Links, including an added link to the released API docs, will be
  updated post release)
 
  Tag:
  http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_7_RC3
 
  Votes, please.  This vote will close in 72 hours, 14-DEC-01:00 GMT.
 
  [ ] +1 I support this release
  [ ] +0 OK, but...
  [ ] -0 Not happy about this because...
  [ ] -1 I oppose this release
 
  Thanks!
 
  Phil
 
  -
  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




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



-- 
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] Release pool 1.5.7 based on RC3

2011-12-11 Thread Phil Steitz

On 12/11/11 11:21 AM, Christian Grobmeier wrote:
 On Sun, Dec 11, 2011 at 7:18 PM, Gary Gregory garydgreg...@gmail.com wrote:
 On Sun, Dec 11, 2011 at 12:56 PM, Christian Grobmeier
 grobme...@gmail.comwrote:

 +1

 checked sigs, site, opened all that stuff, runned test... looks all ok so
 far.
 Not providing a test jar is ok for me (or is this a Commons poilicy??
 have missed it somehow) as I can run the tests from the provided src
 package.

 On Garys comments with M2/M3:
 Tests can be run from the source package, which I have with Maven
 3.0.3 (and with success :-))

 I think building site is not so important as running tests. For
 building the site with M3 one must adjust the pom file - I am not sure
 if it would run with M2 then.

 FYI: Commons parent makes sure that M2 and M3 works, if you use a recent CP
 version that is.
 Thanks for the hint, didn't know it. Actually now I think components
 should always upgrade to the recent cp before a new release.
 I still give +1, but would love to see pool upgrading to recent cp
 with the next release, if possible.

The 2.0 branch will use whatever the latest build is, unless we
decide to do something radical like dump the parent or maven
altogether ;)

I would like to keep the 1.5.x maintenance branch stable in any case.

Phil

 Cheers
 Christian

 Gary


 Anyway, I think it is more the question
 if whole Commons should use one build tool because it is much easier
 for the user to just have one thing installed.

 Cheers
 Christian



 On Sun, Dec 11, 2011 at 1:29 AM, Phil Steitz phil.ste...@gmail.com
 wrote:
 This is a patch release, including a couple of bug fixes.

 The release artifacts are here:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/

 Release notes:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/RELEASE-NOTES.txt

 Maven distribution:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/maven

 Site:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/docs
 (Links, including an added link to the released API docs, will be
 updated post release)

 Tag:
 http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_7_RC3

 Votes, please.  This vote will close in 72 hours, 14-DEC-01:00 GMT.

 [ ] +1 I support this release
 [ ] +0 OK, but...
 [ ] -0 Not happy about this because...
 [ ] -1 I oppose this release

 Thanks!

 Phil

 -
 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



 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
 Spring Batch in Action: http://s.apache.org/HOqhttp://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: [VOTE] Release pool 1.5.7 based on RC3

On Sun, Dec 11, 2011 at 7:39 PM, Phil Steitz phil.ste...@gmail.com wrote:
 On 12/11/11 11:21 AM, Christian Grobmeier wrote:
 On Sun, Dec 11, 2011 at 7:18 PM, Gary Gregory garydgreg...@gmail.com wrote:

 FYI: Commons parent makes sure that M2 and M3 works, if you use a recent CP
 version that is.
 Thanks for the hint, didn't know it. Actually now I think components
 should always upgrade to the recent cp before a new release.
 I still give +1, but would love to see pool upgrading to recent cp
 with the next release, if possible.

 The 2.0 branch will use whatever the latest build is, unless we
 decide to do something radical like dump the parent or maven
 altogether ;)

 I would like to keep the 1.5.x maintenance branch stable in any case.

Makes sense to me :-)

Cheers
Christian


 Phil

 Cheers
 Christian

 Gary


 Anyway, I think it is more the question
 if whole Commons should use one build tool because it is much easier
 for the user to just have one thing installed.

 Cheers
 Christian



 On Sun, Dec 11, 2011 at 1:29 AM, Phil Steitz phil.ste...@gmail.com
 wrote:
 This is a patch release, including a couple of bug fixes.

 The release artifacts are here:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/

 Release notes:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/RELEASE-NOTES.txt

 Maven distribution:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/maven

 Site:
 http://people.apache.org/~psteitz/pool-1.5.7-rc3/docs
 (Links, including an added link to the released API docs, will be
 updated post release)

 Tag:
 http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_7_RC3

 Votes, please.  This vote will close in 72 hours, 14-DEC-01:00 GMT.

 [ ] +1 I support this release
 [ ] +0 OK, but...
 [ ] -0 Not happy about this because...
 [ ] -1 I oppose this release

 Thanks!

 Phil

 -
 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



 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
 Spring Batch in Action: http://s.apache.org/HOqhttp://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




-- 
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: [dbutils] Releasing 1.5

2011-12-11 Thread William Speirs

Clearly I did something wrong:
http://vmbuild.apache.org/continuum/buildResult.action?projectId=74projectName=buildId=15727projectGroupId=0

Also, how can I manually kick-off a contunuum build and/or simulate
that environment on my computer? It builds and tests without error on
my system.

Thanks...

Bill-

On Thu, Dec 8, 2011 at 2:57 PM, sebb seb...@gmail.com wrote:
 On 8 December 2011 18:59, William Speirs wspe...@apache.org wrote:
 Looks like myself, Gary Gregory, Henri Yandell, and Simone Tripodi are
 all +1 on requiring Java 1.6. Sebb is a dissenting opinion, but
 without an official -1.

 When I get a chance, I'm going to change the pom to require Java 1.6
 and make a note in the changes.xml file as well. If that builds with
 Continuum, then I'll attempt to cut an RC release.

 The clirr plugin  section can be removed from the POM as it is
 inherited from CP 22.

 Likewise the maven-compiler-plugin section

 Thanks to everyone for their help/guidance...

 Bill-

 On Thu, Dec 8, 2011 at 1:11 PM, Simone Tripodi simonetrip...@apache.org 
 wrote:
 Hi!


 Reading more, this (getSQLXML) sounds like a good reason to move to Java 
 1.6.

 DB code is tied to JDBC, which is tied to version of Java. Java 5 is
 dead and the only reason I'd heard to consider 5 was Android, which
 doesn't feel like it should a big database client codebase.

 So +1 to moving to Java 6.

 Hen


 that sound valid reasons to me too, +1 :)
 -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


 -
 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: [VOTE] Release JEXL 2.1 based on RC3

2011-12-11 Thread henrib

On checkstyle, 3 of them are empty statements that are known - been there for
long - and the other are Javadoc on deprecated methods introduced to ensure
binary compatibility.

On PMD, I've never tried to configure it correctly; there was already a lot
of clutter in 1.1...
A lot of the issues come from number of methods - but there is no choice
since we derive/implement either Javacc generated code or List (at least for
3/4) and in the former case, a lot of import (one per type of ASTNode).
Another lot are the x != y conditions; PMD says bad style, I tend to like
it to avoid long imbricated if chains and a fail early workflow.
The use of == on object references instead of equals is another bad
habit I tend to use for special cases / constant values. For instance,
trying to make a difference between an empty but modifiable list/map and the
empty non-modifiable instance; this avoids null checking later on
(iteration, access, etc).
And the last bunch is parameter reuse which again, is convenient when using
'null' as marker for default value.
When you factor those out, there is not much left (cyclomatic
complexity...).

Anyway, those are not new. May be I tend to focus too much on checkstyle,
find bugs and cobertura to give me a quality assessment.
I'll try to see if anything can be either better configured or styled
better in v3.
Cheers,
Henrib

--
View this message in context:
http://apache-commons.680414.n4.nabble.com/VOTE-Release-JEXL-2-1-based-on-RC3-tp4174001p4183636.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] Release Apache Commons Gigester 3.2 based on RC2

2011-12-11 Thread Oliver Heger


Am 11.12.2011 18:43, schrieb Simone Tripodi:

Hello!!!

@Oliver: thanks for reviewing! can you tell me please where did you
notice about 3.0 in the release note? I was sure I fixed it on both
/trunk and RC, see[1]... Thanks!!


The version in [1] is alright. But then it seems that the binary and 
source distributions contain an older version of the release notes. I 
checked RELEASE-NOTES.txt from the unzipped distributions.


Oliver



@Paul: looks like the 'Gigester' name is getting more success than the
Digester itself :D

All the best,
-Simo

[1] http://people.apache.org/builds/commons/digester/3.2/RC2/RELEASE-NOTES.txt


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



On Sun, Dec 11, 2011 at 6:30 PM, Paul Benedictpbened...@apache.org  wrote:

Any product called the Gigester gets my +1 vote!

On Sun, Dec 11, 2011 at 10:56 AM, Oliver Hegeroliver.he...@oliver-heger.de

wrote:



+1

Build works fine with Java 1.5 on Windows 7. Artifacts and site look good.

One minor nit: In the release notes the following recommended dependencies
are listed:
The Recommended Dependency Set for Digester 3.0 is:
   Digester 3.1 + Logging 1.1.1 + BeanUtils 1.8.3

This is a bit confusing due to the different Digester version numbers.
Also, the site lists CGLib as additional dependency.

Oliver

Am 10.12.2011 16:18, schrieb Simone Tripodi:

  Hi all guys,I'm writing to call for a vote to release apache

commons-digester-3.2 based on RC2.
Please take in consideration that: * broken 3.2 links will be fixed
once the site will be deployed; * there is a Clirr violation, but:
1) target class is used for internal use only - there is no way users
can reuse it;   2) arguments type are still assignable.
The vote will stay open for at least 72 hours and closes approximately
on Tuesday 13th, at 3:20pm CET.
Many thanks in advance for reviewing, have a nice day!All the best,-Simo
Release notes:
  http://people.apache.org/**builds/commons/digester/3.2/**
RC2/RELEASE-NOTES.txthttp://people.apache.org/builds/commons/digester/3.2/RC2/RELEASE-NOTES.txt
Tag:
  https://svn.apache.org/repos/**asf/commons/proper/digester/**
tags/DIGESTER3_3_2_RC2/https://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER3_3_2_RC2/
Site:
  
http://people.apache.org/**builds/commons/digester/3.2/**RC2/site/http://people.apache.org/builds/commons/digester/3.2/RC2/site/
Binaries:
  
http://people.apache.org/**builds/commons/digester/3.2/**RC2/binaries/http://people.apache.org/builds/commons/digester/3.2/RC2/binaries/
Maven Artifacts (staged on Nexus)
  https://repository.apache.org/**content/repositories/**
orgapachecommons-310/org/**apache/commons/commons-**digester3/3.2/https://repository.apache.org/content/repositories/orgapachecommons-310/org/apache/commons/commons-digester3/3.2/
[ ] +1 release it[ ] +0 go ahead I don't care[ ] -1 no, do not release
it because... (please explain why)

http://people.apache.org/~**simonetripodi/http://people.apache.org/%7Esimonetripodi/
http://simonetripodi.**livejournal.com/http://simonetripodi.livejournal.com/
http://twitter.com/**simonetripodihttp://twitter.com/simonetripodi
http://www.99soft.org/

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




--**--**-
To unsubscribe, e-mail: 
dev-unsubscribe@commons.**apache.orgdev-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

[VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled

2011-12-11 Thread Siegfried Goeschl


Hi folks,

reviewing the release candidate showed a few problems/discussion points

1) Moving constant from Email.java to EmailConstants,java
==

I made the following change

+) adding EmailConstants
+) Email implements EmailConstants

public interface EmailConstants {}
public abstract class Email implements EmailConstants {}

We have different opinions out there

+) Gary - in general unhappy about an interface containing constants 
only, and see issues with source code and binary compatibility

+) Sebastian - sees no issues with binary compatibility
+) I personally don't see any issues otherwise I would not have made the 
change



2) Renaming of protected fields
==

The code exposes every field as protected which makes me  unhappy since 
the same filed could be accessed using a getter/setter as well. Due to 
EMAIL-105 (https://issues.apache.org/jira/browse/EMAIL-105) I renamed 
two protected fields on order to clarify the behavior


* tls == startTlsEnabled
* ssl == sslOnConnect

The original getters/setters are still there but deprecated now

+) Sebastian pointed out that this breaks binary compatibility
+) I think along the lines that the protected fields should not be used 
at all if there is a getter/setter available


The question - does this change requires a new major release?


3) Return type of setters changed from void to this
==

I changed the return type of setters to support something like this

email.setMailSession()setDebug().setContent();

instead of

email.setMailSession();
email.setDebug();
email.setContent();

+) Sebastian pointed out that this breaks binary compatibility (a 
similar issues happened in commons-io)
+) based on my knowledge I doubt that but have to admit that Sebastian 
knows a lot of things better than I do ... :-)


I thing the way to go is to run the commons-email-1.2 test suite with 
commons-email-1.3 and to report the result


4) The source zip is missing
==

No discussions about that ... :-)


5) OS-dependency in DataSourceFileResolverTest.testResolvingFileLenient
==

No discussions about that ... :-)


6) RAT Complaints
==

The mime.type and four test email messages have no ASL - with the 
newest commons-parent it should be possible to exclude files from RAT



I'm sort of stuck here - IMHO the changes regarding 1), 2) and 3) are 
not big enough to justify a new major release whereas the library has 
enough rough edges to look forward an clean-up and major release. But 
for doing that I simple have not enough time for the next weeks ... any 
opinions out there?


Cheers,

Siegfried Goeschl

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

Re: [VOTE] Release Apache Commons Gigester 3.2 based on RC2

poor me, I wonder why an RC is never perfect :'(
Thanks for the deep review, alles gute!
-Simo

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



On Sun, Dec 11, 2011 at 9:59 PM, Oliver Heger
oliver.he...@oliver-heger.de wrote:
 Am 11.12.2011 18:43, schrieb Simone Tripodi:

 Hello!!!

 @Oliver: thanks for reviewing! can you tell me please where did you
 notice about 3.0 in the release note? I was sure I fixed it on both
 /trunk and RC, see[1]... Thanks!!


 The version in [1] is alright. But then it seems that the binary and source
 distributions contain an older version of the release notes. I checked
 RELEASE-NOTES.txt from the unzipped distributions.

 Oliver


 @Paul: looks like the 'Gigester' name is getting more success than the
 Digester itself :D

 All the best,
 -Simo

 [1]
 http://people.apache.org/builds/commons/digester/3.2/RC2/RELEASE-NOTES.txt


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



 On Sun, Dec 11, 2011 at 6:30 PM, Paul Benedictpbened...@apache.org
  wrote:

 Any product called the Gigester gets my +1 vote!

 On Sun, Dec 11, 2011 at 10:56 AM, Oliver
 Hegeroliver.he...@oliver-heger.de

 wrote:


 +1

 Build works fine with Java 1.5 on Windows 7. Artifacts and site look
 good.

 One minor nit: In the release notes the following recommended
 dependencies
 are listed:
 The Recommended Dependency Set for Digester 3.0 is:
   Digester 3.1 + Logging 1.1.1 + BeanUtils 1.8.3

 This is a bit confusing due to the different Digester version numbers.
 Also, the site lists CGLib as additional dependency.

 Oliver

 Am 10.12.2011 16:18, schrieb Simone Tripodi:

  Hi all guys,I'm writing to call for a vote to release apache

 commons-digester-3.2 based on RC2.
 Please take in consideration that: * broken 3.2 links will be fixed
 once the site will be deployed; * there is a Clirr violation, but:
 1) target class is used for internal use only - there is no way users
 can reuse it;   2) arguments type are still assignable.
 The vote will stay open for at least 72 hours and closes approximately
 on Tuesday 13th, at 3:20pm CET.
 Many thanks in advance for reviewing, have a nice day!All the
 best,-Simo
 Release notes:
  http://people.apache.org/**builds/commons/digester/3.2/**

 RC2/RELEASE-NOTES.txthttp://people.apache.org/builds/commons/digester/3.2/RC2/RELEASE-NOTES.txt
 Tag:
  https://svn.apache.org/repos/**asf/commons/proper/digester/**

 tags/DIGESTER3_3_2_RC2/https://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER3_3_2_RC2/
 Site:

  http://people.apache.org/**builds/commons/digester/3.2/**RC2/site/http://people.apache.org/builds/commons/digester/3.2/RC2/site/
 Binaries:

  http://people.apache.org/**builds/commons/digester/3.2/**RC2/binaries/http://people.apache.org/builds/commons/digester/3.2/RC2/binaries/
 Maven Artifacts (staged on Nexus)
  https://repository.apache.org/**content/repositories/**

 orgapachecommons-310/org/**apache/commons/commons-**digester3/3.2/https://repository.apache.org/content/repositories/orgapachecommons-310/org/apache/commons/commons-digester3/3.2/
 [ ] +1 release it[ ] +0 go ahead I don't care[ ] -1 no, do not release
 it because... (please explain why)


 http://people.apache.org/~**simonetripodi/http://people.apache.org/%7Esimonetripodi/

 http://simonetripodi.**livejournal.com/http://simonetripodi.livejournal.com/
 http://twitter.com/**simonetripodihttp://twitter.com/simonetripodi
 http://www.99soft.org/


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




 --**--**-
 To unsubscribe, e-mail:
 dev-unsubscribe@commons.**apache.orgdev-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


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

Re: [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled

2011-12-11 Thread Siegfried Goeschl


Hi folks,

I ran the commons-email-1.2 test suite with commons-email-1.3 and got

[junit] Running org.apache.commons.mail.EmailTest
[junit] Testsuite: org.apache.commons.mail.EmailTest
[junit] Tests run: 39, Failures: 0, Errors: 17, Time elapsed: 0.252 sec
[junit] Tests run: 39, Failures: 0, Errors: 17, Time elapsed: 0.252 sec

[junit] Testcase: testGetSetSession took 0.012 sec
[junit] Caused an ERROR
[junit] 
org.apache.commons.mail.mocks.MockEmailConcrete.setMailSession(Ljavax/mail/Session;)V
[junit] java.lang.NoSuchMethodError: 
org.apache.commons.mail.mocks.MockEmailConcrete.setMailSession(Ljavax/mail/Session;)V
[junit] 	at 
org.apache.commons.mail.EmailTest.testGetSetSession(EmailTest.java:108)


Well, had another run with some other code getting

ests run: 11, Failures: 0, Errors: 10, Skipped: 0, Time elapsed: 0.451 
sec  FAILURE!
testDefaultDomain(org.apache.fulcrum.commonsemail.CommonsEmailServiceTest) 
 Time elapsed: 0.147 sec   ERROR!
java.lang.NoSuchMethodError: 
org.apache.commons.mail.Email.setAuthentication(Ljava/lang/String;Ljava/lang/String;)V
	at 
org.apache.fulcrum.commonsemail.impl.CommonsEmailServiceImpl.configure(CommonsEmailServiceImpl.java:1007)
	at 
org.apache.fulcrum.commonsemail.impl.CommonsEmailServiceImpl.createSimpleEmail(CommonsEmailServiceImpl.java:285)
	at 
org.apache.fulcrum.commonsemail.CommonsEmailServiceTest.testDefaultDomain(CommonsEmailServiceTest.java:274)



So Sebastian was right ...

+) changing the return type from void to something else breaks binary 
compatibility


+) moving the constants from Email to EmailConstants.java was had no impact


Sebastian, kudos given ... :-)


Cheers,

Siegfried Goeschl



On 11.12.11 22:06, Siegfried Goeschl wrote:

Hi folks,

reviewing the release candidate showed a few problems/discussion points

1) Moving constant from Email.java to EmailConstants,java
==

I made the following change

+) adding EmailConstants
+) Email implements EmailConstants

public interface EmailConstants {}
public abstract class Email implements EmailConstants {}

We have different opinions out there

+) Gary - in general unhappy about an interface containing constants
only, and see issues with source code and binary compatibility
+) Sebastian - sees no issues with binary compatibility
+) I personally don't see any issues otherwise I would not have made the
change


2) Renaming of protected fields
==

The code exposes every field as protected which makes me unhappy since
the same filed could be accessed using a getter/setter as well. Due to
EMAIL-105 (https://issues.apache.org/jira/browse/EMAIL-105) I renamed
two protected fields on order to clarify the behavior

* tls == startTlsEnabled
* ssl == sslOnConnect

The original getters/setters are still there but deprecated now

+) Sebastian pointed out that this breaks binary compatibility
+) I think along the lines that the protected fields should not be used
at all if there is a getter/setter available

The question - does this change requires a new major release?


3) Return type of setters changed from void to this
==

I changed the return type of setters to support something like this

email.setMailSession()setDebug().setContent();

instead of

email.setMailSession();
email.setDebug();
email.setContent();

+) Sebastian pointed out that this breaks binary compatibility (a
similar issues happened in commons-io)
+) based on my knowledge I doubt that but have to admit that Sebastian
knows a lot of things better than I do ... :-)

I thing the way to go is to run the commons-email-1.2 test suite with
commons-email-1.3 and to report the result

4) The source zip is missing
==

No discussions about that ... :-)


5) OS-dependency in DataSourceFileResolverTest.testResolvingFileLenient
==

No discussions about that ... :-)


6) RAT Complaints
==

The mime.type and four test email messages have no ASL - with the
newest commons-parent it should be possible to exclude files from RAT


I'm sort of stuck here - IMHO the changes regarding 1), 2) and 3) are
not big enough to justify a new major release whereas the library has
enough rough edges to look forward an clean-up and major release. But
for doing that I simple have not enough time for the next weeks ... any
opinions out there?

Cheers,

Siegfried Goeschl

-
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

[Graph] On graph weight type(s)

2011-12-11 Thread Claudio Squarcella


Hi all,

I explored a bit more the (rather philosophical) dilemma that came from 
a thread from last week, quoted below
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 :-)


The question is: *what do we mean by weight when dealing with graphs?*

Real number is a standard answer in graph theory: see, e.g., 
http://www.math.jussieu.fr/~jabondy/books/gtwa/pdf/chapter1.pdf (pag. 
15). What we have now in the code is a {{getWeight()}} method that 
returns a double. That serves well for all the algorithms currently 
implemented, and probably for many more to come. However it is also true 
that:


 * some domains of interest and/or algorithms might be more restrictive
   on the type and sign of real number for the weights: integers,
   non-negative rationals, etc.
 * strictly speaking, the basic operations associated with weights are
   usually just a few. Comparison and sum are enough at least for the
   algorithms implemented so far in the project (please correct me if I
   am wrong). Maybe scaling? Additive inverse?
 * each algorithm is aware of the subset of required operations. E.g.
   Prim's algorithm for minimum spanning trees only requires edge
   weights to be comparable, so they could even be Strings or whatever...
 * some very abstract user might want to use a new class (not
   necessarily a number) as a weight, provided that it meets the
   requirements of the domain.

So here is a high-level view of what I propose:

 * the basic weight is nothing more than a {{Comparable}}, which is
   hopefully generic enough;
 * where needed, algorithms define more specific constraints on the
   input graph in their signature (e.g. Dijkstra can use {{Double}}).


Looking forward for comments,
Claudio

--
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: [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled

On 11 December 2011 22:42, Siegfried Goeschl sgoes...@gmx.at wrote:
 Hi folks,

 I ran the commons-email-1.2 test suite with commons-email-1.3 and got

 [junit] Running org.apache.commons.mail.EmailTest
 [junit] Testsuite: org.apache.commons.mail.EmailTest
 [junit] Tests run: 39, Failures: 0, Errors: 17, Time elapsed: 0.252 sec
 [junit] Tests run: 39, Failures: 0, Errors: 17, Time elapsed: 0.252 sec

 [junit] Testcase: testGetSetSession took 0.012 sec
 [junit]         Caused an ERROR
 [junit]
 org.apache.commons.mail.mocks.MockEmailConcrete.setMailSession(Ljavax/mail/Session;)V
 [junit] java.lang.NoSuchMethodError:
 org.apache.commons.mail.mocks.MockEmailConcrete.setMailSession(Ljavax/mail/Session;)V
 [junit]         at
 org.apache.commons.mail.EmailTest.testGetSetSession(EmailTest.java:108)

 Well, had another run with some other code getting

 ests run: 11, Failures: 0, Errors: 10, Skipped: 0, Time elapsed: 0.451 sec
  FAILURE!
 testDefaultDomain(org.apache.fulcrum.commonsemail.CommonsEmailServiceTest)
  Time elapsed: 0.147 sec   ERROR!
 java.lang.NoSuchMethodError:
 org.apache.commons.mail.Email.setAuthentication(Ljava/lang/String;Ljava/lang/String;)V

Note the V at the end - that means void return.

        at
 org.apache.fulcrum.commonsemail.impl.CommonsEmailServiceImpl.configure(CommonsEmailServiceImpl.java:1007)
        at
 org.apache.fulcrum.commonsemail.impl.CommonsEmailServiceImpl.createSimpleEmail(CommonsEmailServiceImpl.java:285)
        at
 org.apache.fulcrum.commonsemail.CommonsEmailServiceTest.testDefaultDomain(CommonsEmailServiceTest.java:274)


 So Sebastian was right ...

 +) changing the return type from void to something else breaks binary
 compatibility

 +) moving the constants from Email to EmailConstants.java was had no impact


 Sebastian, kudos given ... :-)


Thanks; I only know this because I tested it when we had the IO issue
- we wanted to return non-void.

At first I did not believe it myself either: why should it matter if a
void method is changed to return non-void?
It cannot affect existing code, surely?  However, that's not the way
the JVM works; the return type is part of the method sig. used when
finding the method.
[Of course it does not affect source compat; it will compile OK if the
return type is ignored].

 Cheers,

 Siegfried Goeschl




 On 11.12.11 22:06, Siegfried Goeschl wrote:

 Hi folks,

 reviewing the release candidate showed a few problems/discussion points

 1) Moving constant from Email.java to EmailConstants,java
 ==

 I made the following change

 +) adding EmailConstants
 +) Email implements EmailConstants

 public interface EmailConstants {}
 public abstract class Email implements EmailConstants {}

 We have different opinions out there

 +) Gary - in general unhappy about an interface containing constants
 only, and see issues with source code and binary compatibility

 +) Sebastian - sees no issues with binary compatibility
 +) I personally don't see any issues otherwise I would not have made the
 change


 2) Renaming of protected fields
 ==

 The code exposes every field as protected which makes me unhappy since
 the same filed could be accessed using a getter/setter as well. Due to
 EMAIL-105 (https://issues.apache.org/jira/browse/EMAIL-105) I renamed
 two protected fields on order to clarify the behavior

 * tls == startTlsEnabled
 * ssl == sslOnConnect

 The original getters/setters are still there but deprecated now

 +) Sebastian pointed out that this breaks binary compatibility
 +) I think along the lines that the protected fields should not be used
 at all if there is a getter/setter available

 The question - does this change requires a new major release?

Potentially yes.

This is one of the reasons I keep saying that fields should be private.
The only reason for having a non-private field is a constant, i.e.
final, usually public static as well.

Mutable non-private fields make it much harder to show that code
behaves OK; they break data encapsulation rules.

Getters and setters protect the class against accidental or malicious change.

If there is a chance that the fields have been used by external code,
then renaming will break that code.

But before rushing to create a major release, consider whether it is
worth the effort of changing the package now.
Are there any other non-private mutable fields? Classes that should be
made immutable? Other API design errors?

I would make sure that all the non-private fields were deprecated, and
make sure that there are getters/setters instead.

If 3rd party code then misuses the mutable fields, and the code
misbehaves - well at least they were warned.

At a later point, do a thorough review of all the code, and make all
the API breaks at once.
Meanwhile use deprecation and Javadoc to document how to use the code safely.



 3) Return type of setters changed from void to this

Re: [dbutils] Releasing 1.5

On 11 December 2011 19:27, William Speirs wspe...@apache.org wrote:
 Clearly I did something wrong:
 http://vmbuild.apache.org/continuum/buildResult.action?projectId=74projectName=buildId=15727projectGroupId=0

You changed the pom to require a minimum of Java 1.6, but the
Continuum build has yet to be updated.

 Also, how can I manually kick-off a contunuum build and/or simulate
 that environment on my computer? It builds and tests without error on
 my system.

I've added a 1.6 build to Dbutils and queued a build. Hopefully it
won't fail this time.

 Thanks...

 Bill-

 On Thu, Dec 8, 2011 at 2:57 PM, sebb seb...@gmail.com wrote:
 On 8 December 2011 18:59, William Speirs wspe...@apache.org wrote:
 Looks like myself, Gary Gregory, Henri Yandell, and Simone Tripodi are
 all +1 on requiring Java 1.6. Sebb is a dissenting opinion, but
 without an official -1.

 When I get a chance, I'm going to change the pom to require Java 1.6
 and make a note in the changes.xml file as well. If that builds with
 Continuum, then I'll attempt to cut an RC release.

 The clirr plugin  section can be removed from the POM as it is
 inherited from CP 22.

 Likewise the maven-compiler-plugin section

 Thanks to everyone for their help/guidance...

 Bill-

 On Thu, Dec 8, 2011 at 1:11 PM, Simone Tripodi simonetrip...@apache.org 
 wrote:
 Hi!


 Reading more, this (getSQLXML) sounds like a good reason to move to Java 
 1.6.

 DB code is tied to JDBC, which is tied to version of Java. Java 5 is
 dead and the only reason I'd heard to consider 5 was Android, which
 doesn't feel like it should a big database client codebase.

 So +1 to moving to Java 6.

 Hen


 that sound valid reasons to me too, +1 :)
 -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


 -
 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


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

Re: [VOTE] Release JEXL 2.1 based on RC3

On 8 December 2011 19:44, sebb seb...@gmail.com wrote:
Further to the earlier cancelled RC1 vote, here is an updated release
candidate.

The main change since RC1 is that all binary incompatibilities have
been resolved.

Clirr still reports errors for interfaces that have additional
methods, but these are false positives, as the changes only affect
source compatibility.

Compatibility with previous releases
==
Version 2.1 is binary compatible with 2.0.1.

New features in 2.1:

Tag:

https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_1_RC3/

Site:

http://people.apache.org/~sebb/jexl-2.1-RC3

Binaries:

https://repository.apache.org/content/repositories/orgapachecommons-298/org/apache/commons/commons-jexl/

This vote will be open for at least 72 hours, closing no sooner than:
20:00PM GMT, Dec 11th.

[X] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Here's my vote.

I'll summarise the vote tomorrow and proceeed with the release,
assuming nothing bad is found in the meantime.

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

Re: [dbutils] Releasing 1.5

2011-12-11 Thread Bill Speirs

On Sun, Dec 11, 2011 at 7:20 PM, sebb seb...@gmail.com wrote:
 You changed the pom to require a minimum of Java 1.6, but the
 Continuum build has yet to be updated.

How should I have updated the Continuum build?

Thanks for the help...

Bill-

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

Re: [dbutils] Releasing 1.5

On 12 December 2011 00:37, Bill Speirs bill.spe...@gmail.com wrote:
 On Sun, Dec 11, 2011 at 7:20 PM, sebb seb...@gmail.com wrote:
 You changed the pom to require a minimum of Java 1.6, but the
 Continuum build has yet to be updated.

 How should I have updated the Continuum build?

Continuum is not exactly easy to configure (*); I added a build with -Pjava-1.6.

(*) It looks simple, but it's all too easy to accidentally configure
all Commons projects instead of just one.

 Thanks for the help...

 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

Re: [Graph] On graph weight type(s)

2011-12-11 Thread James Carman

I wouldn't restrict the weight to Comparable. What if the user wanted to
provide their own Comparator?
On Dec 11, 2011 7:07 PM, Claudio Squarcella squar...@dia.uniroma3.it
wrote:

Hi all,

I explored a bit more the (rather philosophical) dilemma that came from a
thread from last week, quoted below

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 :-)

The question is: *what do we mean by weight when dealing with graphs?*

Real number is a standard answer in graph theory: see, e.g.,
http://www.math.jussieu.fr/~**jabondy/books/gtwa/pdf/**chapter1.pdfhttp://www.math.jussieu.fr/~jabondy/books/gtwa/pdf/chapter1.pdf(pag.
15). What we have now in the code is a {{getWeight()}} method that
returns a double. That serves well for all the algorithms currently
implemented, and probably for many more to come. However it is also true
that:

* some domains of interest and/or algorithms might be more restrictive
on the type and sign of real number for the weights: integers,
non-negative rationals, etc.
* strictly speaking, the basic operations associated with weights are
usually just a few. Comparison and sum are enough at least for the
algorithms implemented so far in the project (please correct me if I
am wrong). Maybe scaling? Additive inverse?
* each algorithm is aware of the subset of required operations. E.g.
Prim's algorithm for minimum spanning trees only requires edge
weights to be comparable, so they could even be Strings or whatever...
* some very abstract user might want to use a new class (not
necessarily a number) as a weight, provided that it meets the
requirements of the domain.

So here is a high-level view of what I propose:

* the basic weight is nothing more than a {{Comparable}}, which is
hopefully generic enough;
* where needed, algorithms define more specific constraints on the
input graph in their signature (e.g. Dijkstra can use {{Double}}).

Looking forward for comments,
Claudio

--
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/~**squarcelhttp://www.dia.uniroma3.it/~squarcel

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

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

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-exec-test has an issue affecting its community integration.
This issue affects 1 projects,
 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 24 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/exec]
M2_HOME: /opt/maven2
-
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.021 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.030 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 8016 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.839 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 12 02:34:45 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 1112122011, vmgump.apache.org:vmgump:1112122011
Gump E-mail Identifier (unique within run) #17.

--
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: [dbutils] Releasing 1.5

2011-12-11 Thread William Speirs

Looks like it worked!

[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 25 seconds
[INFO] Finished at: Mon Dec 12 01:33:42 UTC 2011

Bill-

On Sun, Dec 11, 2011 at 7:44 PM, sebb seb...@gmail.com wrote:
 On 12 December 2011 00:37, Bill Speirs bill.spe...@gmail.com wrote:
 On Sun, Dec 11, 2011 at 7:20 PM, sebb seb...@gmail.com wrote:
 You changed the pom to require a minimum of Java 1.6, but the
 Continuum build has yet to be updated.

 How should I have updated the Continuum build?

 Continuum is not exactly easy to configure (*); I added a build with 
 -Pjava-1.6.

 (*) It looks simple, but it's all too easy to accidentally configure
 all Commons projects instead of just one.

 Thanks for the help...

 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


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

Re: [Graph] On graph weight type(s)

2011-12-11 Thread James Carman

Sorry, I was on my phone before when I sent that.  Let me elaborate a
bit more.  I would just allow the weights to be of any type.  However,
you can create two different types of scenarios where you either use a
Comparable derivative or you use whatever you want, but you have to
supply a custom Comparator.

On Sun, Dec 11, 2011 at 8:01 PM, James Carman
ja...@carmanconsulting.com wrote:
 I wouldn't restrict the weight to Comparable.  What if the user wanted to
 provide their own Comparator?

 On Dec 11, 2011 7:07 PM, Claudio Squarcella squar...@dia.uniroma3.it
 wrote:

 Hi all,

 I explored a bit more the (rather philosophical) dilemma that came from a
 thread from last week, quoted below

 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 :-)


 The question is: *what do we mean by weight when dealing with graphs?*

 Real number is a standard answer in graph theory: see, e.g.,
 http://www.math.jussieu.fr/~jabondy/books/gtwa/pdf/chapter1.pdf (pag. 15).
 What we have now in the code is a {{getWeight()}} method that returns a
 double. That serves well for all the algorithms currently implemented, and
 probably for many more to come. However it is also true that:

  * some domains of interest and/or algorithms might be more restrictive
   on the type and sign of real number for the weights: integers,
   non-negative rationals, etc.
  * strictly speaking, the basic operations associated with weights are
   usually just a few. Comparison and sum are enough at least for the
   algorithms implemented so far in the project (please correct me if I
   am wrong). Maybe scaling? Additive inverse?
  * each algorithm is aware of the subset of required operations. E.g.
   Prim's algorithm for minimum spanning trees only requires edge
   weights to be comparable, so they could even be Strings or whatever...
  * some very abstract user might want to use a new class (not
   necessarily a number) as a weight, provided that it meets the
   requirements of the domain.

 So here is a high-level view of what I propose:

  * the basic weight is nothing more than a {{Comparable}}, which is
   hopefully generic enough;
  * where needed, algorithms define more specific constraints on the
   input graph in their signature (e.g. Dijkstra can use {{Double}}).


 Looking forward for comments,
 Claudio

 --
 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

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

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-proxy-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 273 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.002 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.032 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.031 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.013 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.apache.commons.proxy.exception.TestDelegateProviderException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.invoker.TestChainInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.027 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.179 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.009 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 12 05:43:34 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:

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