from:"Oliver Heger"

Re: [VOTE] Release Commons Configuration 1.7 based on RC1

2011-08-28 Thread Oliver Heger

Am 28.08.2011 20:08, schrieb Gary Gregory:

What about simply bumping the reqs to java 5?

Gary

The maven build works with the Java-1.4 profile; if this profile is
active, some tests related to vfs2 dependencies are excluded.
Unfortunately I did not test the ant build under Java 1.4 :-(

Vfs is not a test dependency, but it is required at runtime only for a
couple of classes. (This is also listed on the dependencies page.)
Because of that I would like to avoid requiring 1.5 in general.

But you are right, the fact that vfs2 requires Java 1.5 affects the
build and should be mentioned explicitly in the release notes and on the
building page. I will change this.

Oliver

On Aug 28, 2011, at 13:46, Phil Steitz wrote:

On 8/28/11 3:51 AM, Oliver Heger wrote:

This is a vote to release Apache Commons Configuration 1.7 based
on the first RC.

Tag:
http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC1/

Distributions: http://people.apache.org/~oheger/configuration-1.7rc1/

Maven artifacts:
http://people.apache.org/~oheger/configuration-1.7rc1/maven/

Site: http://people.apache.org/~oheger/configuration-1.7rc1/site/

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

Vote will remain open for 72 hours.

The release notes (which are very nice, btw) say that 1.3 compat has
been dropped, but the site says 1.4 is still supported. I get the
following compile error when I try to compile using 1.4 (under Ant)
[javac] bad class file:
/home/psteitz/.m2/repository/org/apache/commons/commons-vfs2/2.0/commons-vfs2-2.0.jar(org/apache/commons/vfs2/FileObject.class)
[javac] class file has wrong version 49.0, should be 48.0
[javac] Please remove or make sure it appears in the correct
subdirectory of the classpath.
[javac] import org.apache.commons.vfs2.FileObject;

The Ant build did not work for me out of the box either. It should
probably be either replaced with a working Ant build or removed. It
tries to pull release versions of dependencies from the apache
snapshots repo and it also looks for JUNIT in ANT_HOME. To get it
to work, I removed the unless key on the test goal, and relied on
the fact that all deps were already in my local repo.

Other than these issues, the release looks great. Could be the
first issue is OK for runtime use, as long as whoever is using the
component under 1.4 pulls in a compatible VFS if this is used. But
it looks like VFS is a required (not test only) dependency, so
unless I am missing something, this means you can't build from
source under 1.4. Does the maven 1.4 profile work here? Sorry I
did not test that.

Phil

Oliver

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

Re: [VOTE] Release Commons Configuration 1.7 based on RC1

2011-08-28 Thread Oliver Heger


Am 28.08.2011 17:31, schrieb Gary Gregory:

The Javadocs links to the JRE are broken:

[ERROR] Error fetching link:
http://java.sun.com/j2se/1.4.2/docs/api/package-list. Ignored it.

The URL to use is:

http://download.oracle.com/javase/1.4.2/docs/api/

Not a blocker, but not pretty either. It makes the Javadoc less convenient.


I also saw this message in the build log, however it does not seem to 
affect the Javadocs generated: the links to JDK classes work fine. Also, 
there is no specific configuration for Javadocs in the pom. Is this 
inherited from the parent pom?


Oliver



Gary

On Sun, Aug 28, 2011 at 11:09 AM, Oliver Heger
wrote:



Am 28.08.2011 13:15, schrieb Luc Maisonobe:

  Le 28/08/2011 12:51, Oliver Heger a écrit :



This is a vote to release Apache Commons Configuration 1.7 based on the
first RC.

Tag:
http://svn.apache.org/repos/**asf/commons/proper/**configuration/tags/**
CONFIGURATION_1_7RC1/<http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC1/>



Distributions: 
http://people.apache.org/~**oheger/configuration-1.7rc1/<http://people.apache.org/%7Eoheger/configuration-1.7rc1/>

Maven artifacts:
http://people.apache.org/~**oheger/configuration-1.7rc1/**maven/<http://people.apache.org/%7Eoheger/configuration-1.7rc1/maven/>

Site: 
http://people.apache.org/~**oheger/configuration-1.7rc1/**site/<http://people.apache.org/%7Eoheger/configuration-1.7rc1/site/>

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



When running junit tests, there are many exceptions thrown, which
appears as [WARN] messages. However, the tests pass. Is this expected
behavior ?



Yes, this is okay, e.g. for tests checking error conditions. You are right
that the tests are a bit verbose, but I hope that this is not a big issue.

Thanks for checking the RC.
Oliver




Luc



Vote will remain open for 72 hours.

Oliver

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




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




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








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

[CANCELED][VOTE] Release Commons Configuration 1.7 based on RC1

2011-08-28 Thread Oliver Heger

This vote is canceled as there are some issues related to the build and 
the release notes.


Thanks for all the feedback!
Oliver

Am 28.08.2011 12:51, schrieb Oliver Heger:

This is a vote to release Apache Commons Configuration 1.7 based on the
first RC.

Tag:
http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC1/


Distributions: http://people.apache.org/~oheger/configuration-1.7rc1/

Maven artifacts:
http://people.apache.org/~oheger/configuration-1.7rc1/maven/

Site: http://people.apache.org/~oheger/configuration-1.7rc1/site/

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

Vote will remain open for 72 hours.

Oliver

-
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 Commons Configuration 1.7 based on RC1

2011-08-29 Thread Oliver Heger

Am 29.08.2011 08:21, schrieb Phil Steitz:

On 8/28/11 11:53 AM, Oliver Heger wrote:

Am 28.08.2011 20:08, schrieb Gary Gregory:

+1 to removing the ant build.

Gary

The ant build files were generated using the maven-ant-plugin. The
whole stuff looks pretty complicated, and I do not like the way it
handles dependencies either. To make it work on my local machine I
also had to slightly modify the generated files because there was
an issue with the OSGi manifest.

Removing the ant build at all would be the easiest solution. Many
Commons components still provide an ant build, but there are also
examples that do not. So I am not sure how to proceed here.

@Phil: Do you now have a working ant build, at least for Java 1.5?

I just committed a working build.xml to trunk. It works for jdk
1.4+, skipping the VFS stuff if the jdk is 1.4. I won't be offended
if you decide to drop it. In any case, the maven-build.xml file
should be removed unless you want to keep the maven-generated ant
build setup.

That's great, many thanks, Phil! If there is a working build now, I
don't see a reason why we should drop support for ant.

I will remove the generated files later.

Oliver

Phil

Oliver

On Aug 28, 2011, at 13:46, Phil Steitz
wrote:

On 8/28/11 3:51 AM, Oliver Heger wrote:

This is a vote to release Apache Commons Configuration 1.7 based
on the first RC.

Tag:
http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC1/

Distributions:
http://people.apache.org/~oheger/configuration-1.7rc1/

Maven artifacts:
http://people.apache.org/~oheger/configuration-1.7rc1/maven/

Site: http://people.apache.org/~oheger/configuration-1.7rc1/site/

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

Vote will remain open for 72 hours.

[javac] class file has wrong version 49.0, should be 48.0
[javac] Please remove or make sure it appears in the correct
subdirectory of the classpath.
[javac] import org.apache.commons.vfs2.FileObject;

The Ant build did not work for me out of the box either. It should
probably be either replaced with a working Ant build or
removed. It
tries to pull release versions of dependencies from the apache
snapshots repo and it also looks for JUNIT in ANT_HOME. To get it
to work, I removed the unless key on the test goal, and relied on
the fact that all deps were already in my local repo.

Phil

Oliver

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 Commons Configuration 1.7 based on RC1

2011-08-29 Thread Oliver Heger

Am 28.08.2011 21:44, schrieb Phil Steitz:

[snip]

I now see how the maven 1.4 profile excludes the classes requiring
1.5. As you suggest, it would be good to add a note on this to the
release notes. IIUC what is going on, the classes excluded from
compilation should also be excluded from the javadoc when built
under 1.4. That may happen under the covers anyway, depending on
how maven prepares the source, but if not, assuming the javadoc
plugin supports excludes, they should be excluded there are well.

Unfortunately, the classes excluded from the compilation are present in
the Javadocs. I had a look at the configuration options of the
javadoc-plugin, but I did not find a possibility to exclude single
classes; excludes seem to be supported for whole packages only.

Unless I missed something obvious, I am afraid we have to live with this
inconsistency.

Oliver

Phil

Oliver

On Aug 28, 2011, at 13:46, Phil Steitz
wrote:

On 8/28/11 3:51 AM, Oliver Heger wrote:

This is a vote to release Apache Commons Configuration 1.7 based
on the first RC.

Tag:
http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC1/

Distributions:
http://people.apache.org/~oheger/configuration-1.7rc1/

Maven artifacts:
http://people.apache.org/~oheger/configuration-1.7rc1/maven/

Site: http://people.apache.org/~oheger/configuration-1.7rc1/site/

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

Vote will remain open for 72 hours.

The Ant build did not work for me out of the box either. It should
probably be either replaced with a working Ant build or
removed. It
tries to pull release versions of dependencies from the apache
snapshots repo and it also looks for JUNIT in ANT_HOME. To get it
to work, I removed the unless key on the test goal, and relied on
the fact that all deps were already in my local repo.

Phil

Oliver

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] Release Commons Configuration 1.7 based on RC2

2011-08-30 Thread Oliver Heger

This is a vote to release Apache Commons Configuration 1.7 based on the 
2nd RC.


There have been the following changes since RC1:
* The ant build file has been improved (many thanks to Phil!)
* The release notes mention that the optional dependency to Commons VFS 
requires Java 1.5+. The page listing runtime dependencies has been 
updated correspondingly.

* Minor improvements of the building page.

Tag: 
http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC2/


Distributions: http://people.apache.org/~oheger/configuration-1.7rc2/

Maven artifacts: 
http://people.apache.org/~oheger/configuration-1.7rc2/maven/


Site: http://people.apache.org/~oheger/configuration-1.7rc2/site/

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

Vote will remain open for 72 hours.

Oliver

-
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 Commons Configuration 1.7 based on RC2

2011-09-01 Thread Oliver Heger


Here is my +1

Oliver
(hoping to remind others to vote as well, otherwise release will be 
problematic)


Am 30.08.2011 22:00, schrieb Oliver Heger:

This is a vote to release Apache Commons Configuration 1.7 based on the
2nd RC.

There have been the following changes since RC1:
* The ant build file has been improved (many thanks to Phil!)
* The release notes mention that the optional dependency to Commons VFS
requires Java 1.5+. The page listing runtime dependencies has been
updated correspondingly.
* Minor improvements of the building page.

Tag:
http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC2/


Distributions: http://people.apache.org/~oheger/configuration-1.7rc2/

Maven artifacts:
http://people.apache.org/~oheger/configuration-1.7rc2/maven/

Site: http://people.apache.org/~oheger/configuration-1.7rc2/site/

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

Vote will remain open for 72 hours.

Oliver

-
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 Commons Configuration 1.7 based on RC2

2011-09-02 Thread Oliver Heger


Am 02.09.2011 02:52, schrieb sebb:

On 2 September 2011 01:18, Gary Gregory  wrote:

On Thu, Sep 1, 2011 at 7:55 PM, sebb  wrote:


On 1 September 2011 22:42, Gary Gregory  wrote:

On Thu, Sep 1, 2011 at 2:25 PM, sebb  wrote:


On 30 August 2011 21:00, Oliver Heger
wrote:

This is a vote to release Apache Commons Configuration 1.7 based on

the

2nd

RC.

There have been the following changes since RC1:
* The ant build file has been improved (many thanks to Phil!)
* The release notes mention that the optional dependency to Commons

VFS

requires Java 1.5+. The page listing runtime dependencies has been

updated

correspondingly.
* Minor improvements of the building page.

Tag:




http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC2/


There are quite a few files without AL headers.
Some are generated Java files, which is OK, but there are some scripts
and other files which could and should have AL headers (assuming that
they are ASF files).

For example:

conf/digesterRules.xml



Why doesn't RAT catch this?


The POM has been set up to exclude the conf directory tree; no idea
why as there is no comment in the POM.



Well, this sounds like a bug in the POM, no?


Yes.


Gary



I used RAT, but not via Maven, so it did not exclude the conf files.



Some background information: This setup is there from the very 
beginning. [configuration] does not yet follow the maven standards for 
directory layout (this is something I would like to address in the next 
release), therefore there is no explicit directory for test files. All 
of them have been placed inside the conf directory.


I will add headers as needed for the non-test files. I hope they are not 
required for test files. Because [configuration] is able to read 
comments, this may even impact some unit tests.


Oliver


Gary




If the file is very short (e.g. one-line css file) there is no need to
add the header.

Not a blocker, but it does make checking releases harder: a lot of the
source files have

@version $Revision: nnn $, $Date: xxx $

The Date field is Locale-dependent, so my checkout of the SVN tag does
not agree with the checkout you used to create the source archive.

If you really want to see a date, use $Id: $; otherwise keep the
$Revision: $ and drop the $Date: $
Thanks.


Distributions: http://people.apache.org/~oheger/configuration-1.7rc2/

Maven artifacts:
http://people.apache.org/~oheger/configuration-1.7rc2/maven/

Site: http://people.apache.org/~oheger/configuration-1.7rc2/site/


Not a blocker, but the description uses Commons Configuration as a
noun; for trademark purposes it needs to be used as an adjective, at
least initially.

For example:

The Commons Configuration software library provides a generic

configuration

...


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


Missing AL headers.

Release otherwise looks OK, and builds/tests using Java 1.4 with Maven
2.2.1.


Vote will remain open for 72 hours.

Oliver

-
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





--
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory



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





--
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory



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




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

Re: [VOTE] Release Commons Configuration 1.7 based on RC2

2011-09-04 Thread Oliver Heger


Am 04.09.2011 17:27, schrieb Phil Steitz:

On 9/2/11 2:59 AM, Oliver Heger wrote:

Am 02.09.2011 02:52, schrieb sebb:

On 2 September 2011 01:18, Gary Gregory
wrote:

On Thu, Sep 1, 2011 at 7:55 PM, sebb   wrote:


On 1 September 2011 22:42, Gary
Gregory   wrote:

On Thu, Sep 1, 2011 at 2:25 PM, sebb   wrote:


On 30 August 2011 21:00, Oliver
Heger
wrote:

This is a vote to release Apache Commons Configuration 1.7
based on

the

2nd

RC.

There have been the following changes since RC1:
* The ant build file has been improved (many thanks to Phil!)
* The release notes mention that the optional dependency to
Commons

VFS

requires Java 1.5+. The page listing runtime dependencies
has been

updated

correspondingly.
* Minor improvements of the building page.

Tag:




http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC2/



There are quite a few files without AL headers.
Some are generated Java files, which is OK, but there are
some scripts
and other files which could and should have AL headers
(assuming that
they are ASF files).

For example:

conf/digesterRules.xml



Why doesn't RAT catch this?


The POM has been set up to exclude the conf directory tree; no
idea
why as there is no comment in the POM.



Well, this sounds like a bug in the POM, no?


Yes.


Gary



I used RAT, but not via Maven, so it did not exclude the conf
files.



Some background information: This setup is there from the very
beginning. [configuration] does not yet follow the maven standards
for directory layout (this is something I would like to address in
the next release), therefore there is no explicit directory for
test files. All of them have been placed inside the conf directory.

I will add headers as needed for the non-test files. I hope they
are not required for test files. Because [configuration] is able
to read comments, this may even impact some unit tests.


I am sorry, Oliver, I did not get to testing this until now.  Are
you rolling another RC including the added headers?  Looks like you
made some other changes as well.  Sorry for missing the gong on the
vote.


My fault, because I did not explicitly cancel the vote.

Yes, I am going to roll another RC soon.

Thanks
Oliver



Phil


Oliver


Gary




If the file is very short (e.g. one-line css file) there is
no need to
add the header.

Not a blocker, but it does make checking releases harder: a
lot of the
source files have

@version $Revision: nnn $, $Date: xxx $

The Date field is Locale-dependent, so my checkout of the SVN
tag does
not agree with the checkout you used to create the source
archive.

If you really want to see a date, use $Id: $; otherwise keep the
$Revision: $ and drop the $Date: $
Thanks.


Distributions:
http://people.apache.org/~oheger/configuration-1.7rc2/

Maven artifacts:
http://people.apache.org/~oheger/configuration-1.7rc2/maven/

Site:
http://people.apache.org/~oheger/configuration-1.7rc2/site/


Not a blocker, but the description uses Commons Configuration
as a
noun; for trademark purposes it needs to be used as an
adjective, at
least initially.

For example:

The Commons Configuration software library provides a generic

configuration

...


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


Missing AL headers.

Release otherwise looks OK, and builds/tests using Java 1.4
with Maven
2.2.1.


Vote will remain open for 72 hours.

Oliver

-

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





--
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory



-

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





--
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory



-

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




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





-
To unsubscribe, e

Re: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

2011-09-04 Thread Oliver Heger


Am 02.09.2011 17:08, schrieb sebb AT ASF:

I've updated to the latest versions of all the plugins.

Some of these changes may well cause problems, but the best way to
find this out is for various people to try using the POM, so I've
uploaded 22-SNAPSHOT to the snapshot repo.

Please report any issues with using 22-SNAPSHOT (you have to
temporarily update your pom to use it; it does not happen
automatically).

S///


I tested the new snapshot version with [configuration]. Both building 
the jar and the site succeed.


However, the generated site has some defects: The navigation is missing 
some links, e.g. for project info and reports. Also, the header and the 
logo are not displayed correctly. It seems that elements inherited from 
the template for all commons sites are not processed.


Oliver



On 2 September 2011 15:58,  wrote:

Author: sebb
Date: Fri Sep  2 14:58:22 2011
New Revision: 1164565

URL: http://svn.apache.org/viewvc?rev=1164565&view=rev
Log:
Update to latest versions of plugins
TODO - these need checking on projects

Modified:
commons/proper/commons-parent/trunk/pom.xml

Modified: commons/proper/commons-parent/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1164565&r1=1164564&r2=1164565&view=diff
==
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Fri Sep  2 14:58:22 2011
@@ -151,7 +151,7 @@
 
   org.apache.maven.plugins
   maven-compiler-plugin
-2.1
+2.3.2
   
 ${maven.compile.source}
 ${maven.compile.target}
@@ -164,12 +164,12 @@
 
   org.apache.maven.plugins
   maven-deploy-plugin
-2.6
+2.7
 
 
   org.apache.maven.plugins
   maven-gpg-plugin
-1.3
+1.4
 
 
   org.apache.maven.plugins
@@ -179,7 +179,7 @@
 
   org.apache.maven.plugins
   maven-jar-plugin
-2.3
+2.3.2
 
 
   org.apache.maven.plugins
@@ -227,7 +227,7 @@
 
   org.apache.maven.plugins
   maven-site-plugin
-2.2
+3.0
 
 
   org.apache.maven.plugins
@@ -259,8 +259,7 @@
 
   org.apache.felix
   maven-bundle-plugin
-
-1.4.3
+2.3.5
   true
 
   





-
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] Release Commons Configuration 1.7 based on RC3

2011-09-04 Thread Oliver Heger

This is a vote to release Apache Commons Configuration 1.7 based on the 
3rd RC.


There have been the following changes since RC2:
* Some files in the conf directory have been added Apache license 
headers. (Note that the majority of files in this folder are simple test 
files used by unit tests and do not have license headers.)
* Minor changes in the wording of the site and the release notes related 
to trademark policy as suggested by sebb.


Tag: 
http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC3/


Distributions: http://people.apache.org/~oheger/configuration-1.7rc3/

Maven artifacts: 
http://people.apache.org/~oheger/configuration-1.7rc3/maven/


Site: http://people.apache.org/~oheger/configuration-1.7rc3/site/

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

Vote will remain open for 72 hours.

Oliver

-
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: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

2011-09-05 Thread Oliver Heger


Am 05.09.2011 02:03, schrieb sebb:

On 4 September 2011 20:07, Oliver Heger  wrote:

Am 02.09.2011 17:08, schrieb sebb AT ASF:


I've updated to the latest versions of all the plugins.

Some of these changes may well cause problems, but the best way to
find this out is for various people to try using the POM, so I've
uploaded 22-SNAPSHOT to the snapshot repo.

Please report any issues with using 22-SNAPSHOT (you have to
temporarily update your pom to use it; it does not happen
automatically).

S///


I tested the new snapshot version with [configuration]. Both building the
jar and the site succeed.

However, the generated site has some defects: The navigation is missing some
links, e.g. for project info and reports. Also, the header and the logo are
not displayed correctly. It seems that elements inherited from the template
for all commons sites are not processed.


What was the last comons parent version for which the site did build correctly?


Version 21.

But it seems Jörg has found a solution for this problem.

Oliver




Oliver



On 2 September 2011 15:58,wrote:


Author: sebb
Date: Fri Sep  2 14:58:22 2011
New Revision: 1164565

URL: http://svn.apache.org/viewvc?rev=1164565&view=rev
Log:
Update to latest versions of plugins
TODO - these need checking on projects

Modified:
commons/proper/commons-parent/trunk/pom.xml

Modified: commons/proper/commons-parent/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1164565&r1=1164564&r2=1164565&view=diff

==
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Fri Sep  2 14:58:22 2011
@@ -151,7 +151,7 @@
 
   org.apache.maven.plugins
   maven-compiler-plugin
-2.1
+2.3.2
   
 ${maven.compile.source}
 ${maven.compile.target}
@@ -164,12 +164,12 @@
 
   org.apache.maven.plugins
   maven-deploy-plugin
-2.6
+2.7
 
 
   org.apache.maven.plugins
   maven-gpg-plugin
-1.3
+1.4
 
 
   org.apache.maven.plugins
@@ -179,7 +179,7 @@
 
   org.apache.maven.plugins
   maven-jar-plugin
-2.3
+2.3.2
 
 
   org.apache.maven.plugins
@@ -227,7 +227,7 @@
 
   org.apache.maven.plugins
   maven-site-plugin
-2.2
+3.0
 
 
   org.apache.maven.plugins
@@ -259,8 +259,7 @@
 
   org.apache.felix
   maven-bundle-plugin
-
-1.4.3
+2.3.5
   true
 
   





-
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 Commons Configuration 1.7 based on RC3

2011-09-05 Thread Oliver Heger


Hi Gary,

Am 05.09.2011 19:27, schrieb Gary Gregory:

Or maybe we should push this one out and then update everything in trunk...


this was indeed my plan. The last version came out in December 2008, so 
a release is overdue.


I hope to be able to work on a version 1.8 afterwards which targets Java 
1.5 - no big changes, but some polishing of the API which can hopefully 
be binary compatible. This is a good opportunity to update all 
dependencies to the newest Commons components which are already on Java 1.5.





So +1 from me with a note that src/site/xdoc/style/project.css should have a
license header for completness' sake for the next go around (it's a one
liner file I know ;)


Thanks.
Oliver



Gary

On Sun, Sep 4, 2011 at 4:33 PM, Gary Gregory  wrote:


I'm all for updating to the latest and greatest of all components.

Gary

On Sep 4, 2011, at 15:41, Oliver Heger
wrote:


This is a vote to release Apache Commons Configuration 1.7 based on the

3rd RC.


There have been the following changes since RC2:
* Some files in the conf directory have been added Apache license

headers. (Note that the majority of files in this folder are simple test
files used by unit tests and do not have license headers.)

* Minor changes in the wording of the site and the release notes related

to trademark policy as suggested by sebb.


Tag:

http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC3/


Distributions: http://people.apache.org/~oheger/configuration-1.7rc3/

Maven artifacts:

http://people.apache.org/~oheger/configuration-1.7rc3/maven/


Site: http://people.apache.org/~oheger/configuration-1.7rc3/site/

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

Vote will remain open for 72 hours.

Oliver

-
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 Commons Configuration 1.7 based on RC3

2011-09-05 Thread Oliver Heger


Hi Simone,

IIUC Digester 2.x requires JDK 1.5 while this version of Configuration 
still targets 1.4. My plan is that the next version will go for 1.5, 
then we will of course update the dependencies.


Please see also my response to Gary's mail.

Oliver

Am 04.09.2011 21:52, schrieb Simone Tripodi:

Hallo Oliver,
I'm reviewing the tag and, sorry for not having noticed before, is
there any reason why the Digester is still at 1.8 version?
Upgrade to at least 2.1 should be painless enough, even if an upgrade
to 3.0 would be nicer :P
Anyway, not a blocker, just the time of reviewing all the stuff and
express my vote :)
Have a nice day, all the best!
Simo

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



On Sun, Sep 4, 2011 at 9:40 PM, Oliver Heger
  wrote:

This is a vote to release Apache Commons Configuration 1.7 based on the 3rd
RC.

There have been the following changes since RC2:
* Some files in the conf directory have been added Apache license headers.
(Note that the majority of files in this folder are simple test files used
by unit tests and do not have license headers.)
* Minor changes in the wording of the site and the release notes related to
trademark policy as suggested by sebb.

Tag:
http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC3/

Distributions: http://people.apache.org/~oheger/configuration-1.7rc3/

Maven artifacts:
http://people.apache.org/~oheger/configuration-1.7rc3/maven/

Site: http://people.apache.org/~oheger/configuration-1.7rc3/site/

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

Vote will remain open for 72 hours.

Oliver

-
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: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

2011-09-05 Thread Oliver Heger


Am 05.09.2011 15:52, schrieb sebb:

On 5 September 2011 10:42, Oliver Heger  wrote:

Am 05.09.2011 02:03, schrieb sebb:


On 4 September 2011 20:07, Oliver Heger
  wrote:


Am 02.09.2011 17:08, schrieb sebb AT ASF:


I've updated to the latest versions of all the plugins.

Some of these changes may well cause problems, but the best way to
find this out is for various people to try using the POM, so I've
uploaded 22-SNAPSHOT to the snapshot repo.

Please report any issues with using 22-SNAPSHOT (you have to
temporarily update your pom to use it; it does not happen
automatically).

S///


I tested the new snapshot version with [configuration]. Both building the
jar and the site succeed.

However, the generated site has some defects: The navigation is missing
some
links, e.g. for project info and reports. Also, the header and the logo
are
not displayed correctly. It seems that elements inherited from the
template
for all commons sites are not processed.


What was the last comons parent version for which the site did build
correctly?


Version 21.

But it seems Jörg has found a solution for this problem.


I've tried building the configuration site with

mvn site -DskipTests -Dmaven.javadoc.skip -Dmaven.clover.skip -Dcobertura.skip

(the skips are to speed it up)

When I compare the output for parent 21 and parent 22-SNAPSHOT there
are quite a few differences which are due to ordering changes in
reports and html attributes, but I don't see any obvious missing
links.

Tried with both Maven 2.2.1 and 3.0.3.

So what are some of the errors you have seen?
And what command did you use to create the site?

The only minor issue I can see is that the configuration site.xml has
leading / for some links; these are not necessary and should be
removed.


I used the command mvn clean site:site, maven version is 2.2.1 on 
Windows 7, JDK 1.6. I uploaded the results at

http://people.apache.org/~oheger/configuration-site/

The same command with commons-parent 21 produced the site which is part 
of the ongoing vote for the configuration release:

http://people.apache.org/~oheger/configuration-1.7rc3/site/

Oliver




Oliver




Oliver



On 2 September 2011 15:58,  wrote:


Author: sebb
Date: Fri Sep  2 14:58:22 2011
New Revision: 1164565

URL: http://svn.apache.org/viewvc?rev=1164565&view=rev
Log:
Update to latest versions of plugins
TODO - these need checking on projects

Modified:
commons/proper/commons-parent/trunk/pom.xml

Modified: commons/proper/commons-parent/trunk/pom.xml
URL:

http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1164565&r1=1164564&r2=1164565&view=diff


==
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Fri Sep  2 14:58:22
2011
@@ -151,7 +151,7 @@
 
   org.apache.maven.plugins
   maven-compiler-plugin
-2.1
+2.3.2
   
 ${maven.compile.source}
 ${maven.compile.target}
@@ -164,12 +164,12 @@
 
   org.apache.maven.plugins
   maven-deploy-plugin
-2.6
+2.7
 
 
   org.apache.maven.plugins
   maven-gpg-plugin
-1.3
+1.4
 
 
   org.apache.maven.plugins
@@ -179,7 +179,7 @@
 
   org.apache.maven.plugins
   maven-jar-plugin
-2.3
+2.3.2
 
 
   org.apache.maven.plugins
@@ -227,7 +227,7 @@
 
   org.apache.maven.plugins
   maven-site-plugin
-2.2
+3.0
 
 
   org.apache.maven.plugins
@@ -259,8 +259,7 @@
 
   org.apache.felix
   maven-bundle-plugin
-
-1.4.3
+2.3.5
   true
 
   





-
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




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

Re: [ALL] parent plugin updates [was: svn commit: r1164565 - /commons/proper/commons-parent/trunk/pom.xml]

2011-09-06 Thread Oliver Heger


Am 06.09.2011 04:40, schrieb sebb:

On 5 September 2011 21:20, sebb  wrote:

On 5 September 2011 19:19, Oliver Heger  wrote:

Am 05.09.2011 15:52, schrieb sebb:


On 5 September 2011 10:42, Oliver Heger
  wrote:


Am 05.09.2011 02:03, schrieb sebb:


On 4 September 2011 20:07, Oliver Heger
  wrote:


Am 02.09.2011 17:08, schrieb sebb AT ASF:


I've updated to the latest versions of all the plugins.

Some of these changes may well cause problems, but the best way to
find this out is for various people to try using the POM, so I've
uploaded 22-SNAPSHOT to the snapshot repo.

Please report any issues with using 22-SNAPSHOT (you have to
temporarily update your pom to use it; it does not happen
automatically).

S///


I tested the new snapshot version with [configuration]. Both building
the
jar and the site succeed.

However, the generated site has some defects: The navigation is missing
some
links, e.g. for project info and reports. Also, the header and the logo
are
not displayed correctly. It seems that elements inherited from the
template
for all commons sites are not processed.


What was the last comons parent version for which the site did build
correctly?


Version 21.

But it seems Jörg has found a solution for this problem.


I've tried building the configuration site with

mvn site -DskipTests -Dmaven.javadoc.skip -Dmaven.clover.skip
-Dcobertura.skip

(the skips are to speed it up)

When I compare the output for parent 21 and parent 22-SNAPSHOT there
are quite a few differences which are due to ordering changes in
reports and html attributes, but I don't see any obvious missing
links.

Tried with both Maven 2.2.1 and 3.0.3.

So what are some of the errors you have seen?
And what command did you use to create the site?

The only minor issue I can see is that the configuration site.xml has
leading / for some links; these are not necessary and should be
removed.


I used the command mvn clean site:site, maven version is 2.2.1 on Windows 7,
JDK 1.6. I uploaded the results at
http://people.apache.org/~oheger/configuration-site/


I see - looks like the site has been generated from the local site.xml
only, completely ignoring commons parent site.xml

I suspect your local repo does not have the site.xml file - have a
look and see, it should be under

\repository\org\apache\commons\commons-parent\22-SNAPSHOT

I just checked, and the site.xml file has been uploaded to the SNAPSHOT repo at:

https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-parent/22-SNAPSHOT/

but when I tried deleting the local copy, only the pom was downloaded
from the snapshot repo - maybe a bug in Maven?


I tried to reproduce the error to report the issue, and initially it
apppeared to show that site.xml was not being downloaded.
However, now I cannot get the download to fail. No idea why it has
suddenly started working for me.

Note that the site.xml is only downloaded as part of the Maven site processing.

I've also updated the snapshot; there were stale references to site
v2.2 and 3.0-beta3.


Did some more testing: Obviously, there was actually something wrong 
with site.xml in my local repository. There were two site.xml files 
(standard and _en), but both were empty.


I did a fresh checkout of commons-parent and built it using mvn install, 
and this helped. Now I have a correct site.xml in my local repository.


Consequently the site looks much better now. The only difference I 
noticed is that excludes for the RAT plug-in seem to behave differently 
now. In the configuration pom the conf directory is excluded, but 
nevertheless the RAT report lists the files with unknown licenses.


Oliver




To fix this, update to the current commons-parent, and use mvn install
from your local workspace.


The same command with commons-parent 21 produced the site which is part of
the ongoing vote for the configuration release:
http://people.apache.org/~oheger/configuration-1.7rc3/site/

Oliver




Oliver




Oliver



On 2 September 2011 15:58,wrote:


Author: sebb
Date: Fri Sep  2 14:58:22 2011
New Revision: 1164565

URL: http://svn.apache.org/viewvc?rev=1164565&view=rev
Log:
Update to latest versions of plugins
TODO - these need checking on projects

Modified:
commons/proper/commons-parent/trunk/pom.xml

Modified: commons/proper/commons-parent/trunk/pom.xml
URL:


http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1164565&r1=1164564&r2=1164565&view=diff



==
--- commons/proper/commons-parent/trunk/pom.xml (original)
+++ commons/proper/commons-parent/trunk/pom.xml Fri Sep  2 14:58:22
2011
@@ -151,7 +151,7 @@
 
   org.apache.maven.plugins
   maven-compiler-plugin
-2.1
+2.3.2
   
 ${maven.compile.source}
 ${maven.compile.target}
@@ -164,12 +164,12 @@
 
   org.apache.maven.plugins

[RESULT] Release Commons Configuration 1.7 based on RC3

2011-09-07 Thread Oliver Heger


This vote has passed with binding +1 votes by the following people:

Simone Tripodi
Gary Gregory
Phil Steitz

(and my implicit +1 vote. There were no other votes.)

Thanks to all who voted and gave feedback. I will start with the release 
procedure soon.


Oliver

Am 04.09.2011 21:40, schrieb Oliver Heger:

This is a vote to release Apache Commons Configuration 1.7 based on the
3rd RC.

There have been the following changes since RC2:
* Some files in the conf directory have been added Apache license
headers. (Note that the majority of files in this folder are simple test
files used by unit tests and do not have license headers.)
* Minor changes in the wording of the site and the release notes related
to trademark policy as suggested by sebb.

Tag:
http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_7RC3/


Distributions: http://people.apache.org/~oheger/configuration-1.7rc3/

Maven artifacts:
http://people.apache.org/~oheger/configuration-1.7rc3/maven/

Site: http://people.apache.org/~oheger/configuration-1.7rc3/site/

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

Vote will remain open for 72 hours.

Oliver

-
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

[all] Deploying a component site

2011-09-07 Thread Oliver Heger

This may be a dump question, but I have trouble with deploying the site 
for configuration.


According to [1] a mvn site:deploy should be sufficient to do the job. 
However, maven complains that there are no site information in the 
distribution management element.


Well, this is true for the pom of configuration and also for other 
components. I thought that this information would already be provided by 
the parent pom, no? What am I missing?


TIA
Oliver

[1] http://commons.apache.org/releases/publish-site.html

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

Re: [all] Deploying a component site

2011-09-08 Thread Oliver Heger


Hi Simone,

many thanks for your support, but there seems to be a different problem. 
I did run mvn site:site before. Obviously maven does not know where to 
deploy the site.


Well, it is possible to copy the site per hand to its location at 
people.apache.org. I was also able to adapt the distribution-management 
section of commons-vfs as proposed by Ralph.


But I wonder why there are no default settings for all components. Did 
the components you were working on define their specific 
distribution-management section?


Tante grazie
Oliver

Am 07.09.2011 22:25, schrieb Simone Tripodi:

Hi Oliver!
AFAIK mvn site:deploy has effect only once ran site:site, so the right
way to publish a site is

 mvn site:site site:deploy

I used to run the shortcut

 mvn site-deploy

At least is how it worked for sites I deployed.
HTH, alles gute!
Simo

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



On Wed, Sep 7, 2011 at 10:12 PM, Oliver Heger
  wrote:

This may be a dump question, but I have trouble with deploying the site for
configuration.

According to [1] a mvn site:deploy should be sufficient to do the job.
However, maven complains that there are no site information in the
distribution management element.

Well, this is true for the pom of configuration and also for other
components. I thought that this information would already be provided by the
parent pom, no? What am I missing?

TIA
Oliver

[1] http://commons.apache.org/releases/publish-site.html

-
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

[ANNOUNCEMENT] Commons Configuration 1.7 Released

2011-09-08 Thread Oliver Heger


The Apache Commons team is pleased to announce the availability
of Commons Configuration 1.7.

The Commons Configuration software library provides a generic 
configuration interface which enables an application to read 
configuration data from a variety of sources, e.g. properties files, XML 
documents, JDBC datasources and many more. More information can be found 
at the Configuration main site at

http://commons.apache.org/configuration/

The new release contains numerous bug fixes. There are also some new 
features, e.g. support for file systems for loading configuration sources.


A full list of changes since the previous release can be found in the 
release notes or in the changes report at

http://commons.apache.org/configuration/changes-report.html

Apache Commons Configuration is available in either binary or source 
form from the Configuration downloads page:

http://commons.apache.org/configuration/download_configuration.cgi

(Please remember to verify the provided checksums and/or signatures 
after you have downloaded a distribution!)


Oliver Heger
on behalf of the Apache Commons Team


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

Re: [all] Deploying a component site

2011-09-08 Thread Oliver Heger


Am 08.09.2011 17:40, schrieb Simone Tripodi:

Hi!



Perhaps we should add an example section to Commons Parent, but
commented out, and a note to say it should be included in component
POMs?



+1 I think it would be helpful!


Agreed. This is a good idea.

Oliver





s/sote/site/



hehehe, in Italian we say "the rush wants the calm", typed too hurry :P

Simo

http://people.apache.org/~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: [GUMP@vmgump]: Project commons-configuration (in module apache-commons) failed

2011-09-09 Thread Oliver Heger

After the version number in pom.xml was changed to 1.8-SNAPSHOT the gump 
build fails. IIUC, it still searches for a jar ending in 1.7-SNAPSHOT.


I had a look at the gump descriptor in commons-proper.xml, but I did not 
find a place where the version number is hard-coded. The project 
description for Configuration looks as follows:


 

separateLocalRepository="true">

  













  

Is this the correct file to look at? What could be the problem?

Thanks
Oliver

Am 09.09.2011 09:52, schrieb Gump:

To whom it may engage...

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

Project commons-configuration has an issue affecting its community integration.
This issue affects 2 projects,
  and has been outstanding for 2 runs.
The current state of this project is 'Failed', with reason 'Missing Build 
Outputs'.
For reference only, the following projects are affected by this:
 - commons-configuration :  Apache Commons
 - commons-configuration-test :  Apache Commons


Full details are available at:
 
http://vmgump.apache.org/gump/public/apache-commons/commons-configuration/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
  -DEBUG- Sole jar output [commons-configuration-1.7-SNAPSHOT.jar] identifier 
set to project name
  -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml
  -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/configuration/pom.xml
  -INFO- Failed with reason missing build outputs
  -ERROR- Missing Output: 
/srv/gump/public/workspace/apache-commons/configuration/target/commons-configuration-1.7-SNAPSHOT.jar
  -ERROR- See Directory Listing Work for Missing Outputs
  -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-configuration/gump_work/build_apache-commons_commons-configuration.html
Work Name: build_apache-commons_commons-configuration (Type: Build)
Work ended in a state of : Success
Elapsed: 3 mins 11 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml 
package
[Working Directory: /srv/gump/public/workspace/apache-commons/configuration]
M2_HOME: /opt/maven2
-

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus/1.0.10/plexus-1.0.10.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-15/plexus-container-default-1.0-alpha-15.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-15/plexus-containers-1.0-alpha-15.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus/1.0.9/plexus-1.0.9.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-io/1.0-alpha-3/plexus-io-1.0-alpha-3.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-component-api/1.0-alpha-16/plexus-component-api-1.0-alpha-16.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-16/plexus-containers-1.0-alpha-16.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-utils/1.4.9/plexus-utils-1.4.9.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-interpolation/1.6/plexus-interpolation-1.6.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-archiver/1.0-alpha-12/plexus-archiver-1.0-alpha-12.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-io/1.0-alpha-4/plexus-io-1.0-alpha-4.pom

Downloading: 
http://localhost:8192/maven2/commons-lang/commons-lang/2.1/commons-lang-2.1.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-utils/1.4.9/plexus-utils-1.4.9.jar
Downloading: 
http://localhost:8192/maven2/org/apache/maven/maven-archiver/2.4/maven-archiver-2.4.jar
Downloading: 
http://localhost:8192/maven2/commons-lang/commons-lang/2.1/commons-lang-2.1.jar
277K downloaded  (commons-lang-2.1.jar)


Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-archiver/1.0-alpha-12/plexus-archiver-1.0-alpha-12.jar

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-io/1.0-alpha-4/plexus-io-1.0-alpha-4.jar

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-interpolation/1.6/plexus

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

2011-09-10 Thread Oliver Heger


Am 10.09.2011 06:36, schrieb Stefan Bodewig:

On 2011-09-09, Oliver Heger wrote:


After the version number in pom.xml was changed to 1.8-SNAPSHOT the
gump build fails. IIUC, it still searches for a jar ending in
1.7-SNAPSHOT.



I had a look at the gump descriptor in commons-proper.xml, but I did
not find a place where the version number is hard-coded.


This is because I already fixed it before you 8-)


Ah, this explains it.
Many thanks!
Oliver



Stefan

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




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

Re: [VOTE][sanbox] Graduate [functor] as proper component

2011-09-16 Thread Oliver Heger


+1 for moving [functor] to Commons proper.

Oliver

Am 16.09.2011 10:36, schrieb Simone Tripodi:

Hi all guys,
I've been investing part of my spare time to polish the [functor][1]
component that Matt Benson is brilliantly maintaining and AFAIK it is
in a good state to work on to be released soon.
It is also used in [proxy] in the 2.0 branch, so it could be a lock
for [proxy] to jump to a new version.
Moreover we have a pending good contribution[2] that adds to [functor]
new features.

So please cast your votes:
[ ] +1, let's graduate
[ ] +/-0, share thoughts
[ ] -1, because...

Many thanks in advance, have a nice day!
all the best,
Simo

[1] http://commons.apache.org/sandbox/functor/
[2] https://issues.apache.org/jira/browse/SANDBOX-341

http://people.apache.org/~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

[configuration] Defining variable resolvers in configuration definition files

2012-12-25 Thread Oliver Heger


Hi all,

currently I am working on [CONFIGURATION-518] - rework of interpolation 
features.


DefaultConfigurationBuilder supports that custom variable resolvers can 
be defined in its definition files. I noticed that these resolvers are 
not only used locally, but are also registered as global lookup objects. 
I think, this behavior is pretty invasive, and it does not seem to be 
documented (at least not in the Javadocs of 
DefaultConfigurationBuilder). This seems to be a workaround for making 
such custom resolvers available to other objects (e.g. 
ConfigurationInterpolator objects in DynamicCombinedConfiguration).


I temporarily disabled this mechanism (and had to @Ignore 4 test cases 
which now are failing). I hope to find a better solution based on the 
builders approach I am working on in parallel. In this context, I also 
plan to have a more generic mechanism to define default settings for 
newly created Configuration objects.


Oliver

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

Re: [commons-parent] drop cobertura

2012-12-29 Thread Oliver Heger


Am 29.12.2012 09:43, schrieb Luc Maisonobe:

Hi Phil,

Le 28/12/2012 21:10, Phil Steitz a écrit :

On 12/28/12 11:44 AM, Gary Gregory wrote:

It seems a shame to turn off this feature for ALL projects because one
project can't figure out a workaround.


Can *any* project find a workaround?  Is there *any way* to turn
this thing off?


What about every project being declared in the aggregator project
Olivier set up in our instance of Sonar
?



+1

We could then even disable more reports in the components' poms 
(findbugs, pmd, checkstyle, ...) and just add a link to the Sonar instance.


This would provide comprehensive up-to-date statistics for all 
components. It would also be a step forward in making the components 
more uniform.


Oliver


Luc



Phil


Gary

On Dec 28, 2012, at 12:21, Phil Steitz  wrote:


Any objections to this?  In [math] at least we can't seem to turn it
off and it is causing the site build to take forever.

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




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

Re: [commons-parent] drop cobertura

2012-12-29 Thread Oliver Heger


Am 29.12.2012 21:21, schrieb Phil Steitz:

On 12/29/12 10:44 AM, Mark Struberg wrote:

Any better suggestions for [math]?

Yes, as I see it there are two options.

a.) move some parts into a profile


How exactly would this work?  Can we get rid of stuff that way,
really?  We can get it to ignore stuff the parent specifies?  Or are
you talking about yet another profile in the parent?


Could we move the major part of the reports into a profile which is not 
enabled per default? Then everybody can build a site locally containing 
all these reports by just enabling the profile. The official sites would 
not contain reports, but reference Sonar.


Oliver


b.) create 2 parent pom. One with the infrastructure stuff and one with all the 
tons of additional goodies only needed for the other projects.


That seems pretty ugly.  I wonder how bad it would be, actually, to
just get rid of the parent and define the stuff we actually use /
need in [math] itself.  I think I have on balance spent more time
figuring out what was going on in the parent than I would have spent
just maintaining properties actually used by the components that I
work on.  Maybe just strip it down to some common properties and
things like the mailing lists.  At the very least, we should drop
the reporting section and the one you mention below.




LieGrue,
strub


PS: I find it pretty weird that the commons-parent has a profile to build all the 
other stuff. This can be done much cleaner in having an own build-aggregator pom 
which just contains the .


Agreed.  I wonder if anyone ever uses this.  I would be +1 to drop.

Phil



- Original Message -

From: Phil Steitz 
To: Commons Developers List 
Cc:
Sent: Saturday, December 29, 2012 7:29 PM
Subject: Re: [commons-parent] drop cobertura

On 12/29/12 10:02 AM, Gary Gregory wrote:

  Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
  commons components to Sonar, just do not mess up development for all the
  other components because one class in [math] is not performing acceptably
  for the Cobertura report.

The problem is that the plugin is bugged and effectively impossible
to turn off.

I think the sonar idea is a great one and consistent with what we
have talked about on and off for years - separating the CI-type
development reports from the component sites.  As we are about to go
over the "site deployment cliff ;"  now is a great time to think
about losing some weight :)

I guess an alternative for [math] is to drop commons-parent
entirely, just grabbing the stuff we need.  Any better suggestions
for [math]?

Phil

  Gary


  On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz 

wrote:

  On 12/29/12 9:46 AM, Oliver Heger wrote:

  Am 29.12.2012 09:43, schrieb Luc Maisonobe:

  Hi Phil,

  Le 28/12/2012 21:10, Phil Steitz a écrit :

  On 12/28/12 11:44 AM, Gary Gregory wrote:

  It seems a shame to turn off this feature for ALL

projects

  because one
  project can't figure out a workaround.

  Can *any* project find a workaround?  Is there *any way* to

turn

  this thing off?

  What about every project being declared in the aggregator

project

  Olivier set up in our instance of Sonar
  <https://analysis.apache.org/components/index/121254>?


  +1

  We could then even disable more reports in the components' poms
  (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
  instance.

  This would provide comprehensive up-to-date statistics for all
  components. It would also be a step forward in making the
  components more uniform.

  +1 - and as yet another bonus, it would reduce wasted infra
  resources duplicating all of the images, etc on all of the
  individual sites and the need to store all of that stuff in svn.

  Phil

  Oliver


  Luc


  Phil

  Gary

  On Dec 28, 2012, at 12:21, Phil Steitz



  wrote:


  Any objections to this?  In [math] at least we

can't seem to

  turn it
  off and it is causing the site build to take

forever.

  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




-

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

[configuration] Design discussion

2013-01-01 Thread Oliver Heger


Hi,

recently I have worked on code regarding the creation of Configuration 
objects and reloading support. I have created two Jira tickets [1, 2] 
with a description of the problems I see in the current design.


The code in SVN (mainly in the new builder package) should be sufficient 
to get a good impression about the direction I would like to go. It is 
far more than a pure proof of concept.


However, following this road means some significant changes in the 
design and in the way client code uses our classes. Therefore, I would 
really appreciate feedback from other committers also interested in this 
component.


My main question is: Can we replace the reloading mechanisms available 
in 1.x by an approach based on builders as currently implemented in 
trunk (e.g. classes 
o.a.c.c.builder.ReloadingFileBasedConfigurationBuilder, 
o.a.c.c.reloading.ReloadingController)? If the answer is 'yes', we could 
go forward and significantly simplify most of the file-based 
configuration implementations.


Thanks
Oliver

[1] https://issues.apache.org/jira/browse/CONFIGURATION-519
[2] https://issues.apache.org/jira/browse/CONFIGURATION-520

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

Re: [configuration] Design discussion

2013-01-05 Thread Oliver Heger


Hi Jörg,

Am 04.01.2013 17:47, schrieb Jörg Schaible:

Hi Oliver,

Oliver Heger wrote:


Hi,

recently I have worked on code regarding the creation of Configuration
objects and reloading support. I have created two Jira tickets [1, 2]
with a description of the problems I see in the current design.

The code in SVN (mainly in the new builder package) should be sufficient
to get a good impression about the direction I would like to go. It is
far more than a pure proof of concept.

However, following this road means some significant changes in the
design and in the way client code uses our classes. Therefore, I would
really appreciate feedback from other committers also interested in this
component.

My main question is: Can we replace the reloading mechanisms available
in 1.x by an approach based on builders as currently implemented in
trunk (e.g. classes
o.a.c.c.builder.ReloadingFileBasedConfigurationBuilder,
o.a.c.c.reloading.ReloadingController)? If the answer is 'yes', we could
go forward and significantly simplify most of the file-based
configuration implementations.

Thanks
Oliver

[1] https://issues.apache.org/jira/browse/CONFIGURATION-519
[2] https://issues.apache.org/jira/browse/CONFIGURATION-520


simply go-on with these changes. IMHO it looks good and since separation of
concern leads here to significant code simplification, it's for the best of
us devs and also for our users in the long term. Especially since the new
approach brings also improved functionality.


Thanks for your feedback. Will do!

Oliver



Cheers,
Jörg


-
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 of Commons Email 1.3 based on RC7

2013-01-07 Thread Oliver Heger

Build is successful on Windows 7 with both a JDK 1.5 and 1.7. Artifacts
and site look good.

The only issue I found is that the copyright date in NOTICE.txt is still
2012. However, because there have hardly been changes in 2013, I don't
think that this is a blocker.

So +1
Oliver

Am 06.01.2013 23:25, schrieb Thomas Neidhart:

Hi,

I would like to call a vote for releasing commons-email-1.3 based on RC7.

This release candidate has the following changes compared to RC6:

+) added missing @since tags in class Email
+) update links in release notes
+) change unit tests with invalid URLs to be more reliable (with the
help of powermock: use a mocked URL object which will always fail
when trying to open a connection to it)

The files:

The artifacts are deployed to Nexus:
https://repository.apache.org/content/repositories/orgapachecommons-104/org/apache/commons/commons-email/1.3/

The tag:
https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC7/

The site:
http://people.apache.org/builds/commons/email/1.3/RC7/

Additional Notes:

o the download page and api links to older releases only work on
the published site and will be corrected after release.

Please take a look at the commons-email-1.3 artifacts and vote!

[ ] +1 release it.
[ ] +0 go ahead; I don't care.
[ ] -0 there are a few minor glitches: ...
[ ] -1 no, do not release it because ...

Vote will remain open for at least 72 hours.

Thanks in advance,

Thomas

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

Re: svn commit: r1432062 - /commons/cms-site/trunk/content/resources/.htaccess

2013-01-18 Thread Oliver Heger


Am 18.01.2013 13:47, schrieb Olivier Lamy:

So all has been imported.
see result here: http://people.apache.org/~olamy/commons-content/

For releasing commons parent, the ASF parent pom is on vote on dev@maven
IMHO both proper and sandbox parents must be release.


Great! Many many thanks for all your work!

Oliver

[...]

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

Re: svn commit: r1436768 [1/13] - in /commons/proper/lang/trunk/src: main/java/org/apache/commons/lang3/ main/java/org/apache/commons/lang3/builder/ main/java/org/apache/commons/lang3/concurrent/ main

2013-01-22 Thread Oliver Heger

I don't want to open another can of worms, but just want to state that I 
am not in favor of all those final modifiers except when applied to 
member fields of a class.


IMHO, this makes code harder to read because it only adds clutter. It 
also hides the occasions where final is really required, e.g. when 
accessing a variable from an anonymous class.


Oliver

Am 22.01.2013 08:07, schrieb ggreg...@apache.org:

Author: ggregory
Date: Tue Jan 22 07:07:42 2013
New Revision: 1436768

URL: http://svn.apache.org/viewvc?rev=1436768&view=rev
Log:
Add final modifier to method parameters.

Modified:
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/AnnotationUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/BitField.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/BooleanUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/CharEncoding.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/CharRange.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/CharSequenceUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/CharSet.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/CharSetUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/CharUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ClassUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/EnumUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/JavaVersion.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/LocaleUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ObjectUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/RandomStringUtils.java
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Range.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/SerializationException.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/SerializationUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringEscapeUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/SystemUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Validate.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/builder/CompareToBuilder.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/builder/HashCodeBuilder.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/builder/IDKey.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/builder/ReflectionToStringBuilder.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/builder/StandardToStringStyle.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/builder/ToStringBuilder.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/concurrent/BackgroundInitializer.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/concurrent/BasicThreadFactory.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/concurrent/CallableBackgroundInitializer.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/concurrent/ConcurrentException.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/concurrent/ConcurrentRuntimeException.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/concurrent/ConcurrentUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/concurrent/ConstantInitializer.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/concurrent/MultiBackgroundInitializer.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/concurrent/TimedSemaphore.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/event/EventListenerSupport.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/event/EventUtils.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/exception/ContextedException.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/exception/ContextedRuntimeException.java
 
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/exce

Re: [configuration] Design discussion

2013-01-28 Thread Oliver Heger

(From time to time I am going to post an update about the progress I 
have made so that everybody who is interested can comment.)


Just finished reworking MultiFileConfiguration to use the new builder 
approach. There is now a MultiFileConfigurationBuilder class offering 
pretty much the same functionality plus that it can deal with arbitrary 
file-based configurations.


The class now also works well together with CombinedConfigurationBuilder 
in the same way the old integration was with 
DefaultConfigurationBuilder, i.e. a DynamicCombinedConfiguration is used 
to ensure that a new CombinedConfiguration is constructed every time the 
file pattern changes.


@Ralph: Maybe, as the original author, you find the time to have a short 
look to verify that no features were lost?


CombinedConfigurationBuilder should now provide the same functionality 
as DefaultConfigurationBuilder. With slight exceptions it can process 
the same configuration definition files. So I plan to remove 
DefaultConfigurationBuilder shortly.


Oliver

Am 05.01.2013 16:48, schrieb Oliver Heger:

Hi Jörg,

Am 04.01.2013 17:47, schrieb Jörg Schaible:

Hi Oliver,

Oliver Heger wrote:


Hi,

recently I have worked on code regarding the creation of Configuration
objects and reloading support. I have created two Jira tickets [1, 2]
with a description of the problems I see in the current design.

The code in SVN (mainly in the new builder package) should be sufficient
to get a good impression about the direction I would like to go. It is
far more than a pure proof of concept.

However, following this road means some significant changes in the
design and in the way client code uses our classes. Therefore, I would
really appreciate feedback from other committers also interested in this
component.

My main question is: Can we replace the reloading mechanisms available
in 1.x by an approach based on builders as currently implemented in
trunk (e.g. classes
o.a.c.c.builder.ReloadingFileBasedConfigurationBuilder,
o.a.c.c.reloading.ReloadingController)? If the answer is 'yes', we could
go forward and significantly simplify most of the file-based
configuration implementations.

Thanks
Oliver

[1] https://issues.apache.org/jira/browse/CONFIGURATION-519
[2] https://issues.apache.org/jira/browse/CONFIGURATION-520


simply go-on with these changes. IMHO it looks good and since
separation of
concern leads here to significant code simplification, it's for the
best of
us devs and also for our users in the long term. Especially since the new
approach brings also improved functionality.


Thanks for your feedback. Will do!

Oliver



Cheers,
Jörg


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






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

Re: [configuration] Design discussion

2013-01-29 Thread Oliver Heger


Am 29.01.2013 01:32, schrieb Ralph Goers:

Sure - But as I've worked with CombinedConfiguration I became less enthralled 
with it.  The problem I had with the DynamicCombinedConfiguration was that 
every CombinedConfiguration has to have its own copy of all the configurations. 
Attempting to share a configuration led to all kinds of corruption when the 
file was updated and the tree was modified.  I really wanted to do the same 
thing with CompositeConfiguration but since it didn't officially support XML 
and doesn't have a builder I didn't get around to it.
I don't have a bright idea how to handle this. I hope, situation gets a 
bit better when reloading is done differently; then configuration data 
cannot change completely at any time. It is still on my list for 2.0 to 
implement a mechanism to make configurations optionally thread-safe. 
Hopefully, this leads to a solution for CombinedConfiguration, too.




Ultimately, I would prefer that there only be one ConfigurationBuilder and that 
its end result be a Configuration, not a CombinedConfiguration.  Underneath 
that there could, of course, be various flavors of builders but ideally the 
user wouldn't need to be bothered with them.
Sounds good. Currently I am following a bottom-up approach, i.e. I 
create the various builders first. It should be possible to implement a 
'meta' builder on top later.


Oliver



Ralph


On Jan 28, 2013, at 1:10 PM, Oliver Heger wrote:


(From time to time I am going to post an update about the progress I have made 
so that everybody who is interested can comment.)

Just finished reworking MultiFileConfiguration to use the new builder approach. 
There is now a MultiFileConfigurationBuilder class offering pretty much the 
same functionality plus that it can deal with arbitrary file-based 
configurations.

The class now also works well together with CombinedConfigurationBuilder in the 
same way the old integration was with DefaultConfigurationBuilder, i.e. a 
DynamicCombinedConfiguration is used to ensure that a new CombinedConfiguration 
is constructed every time the file pattern changes.

@Ralph: Maybe, as the original author, you find the time to have a short look 
to verify that no features were lost?

CombinedConfigurationBuilder should now provide the same functionality as 
DefaultConfigurationBuilder. With slight exceptions it can process the same 
configuration definition files. So I plan to remove DefaultConfigurationBuilder 
shortly.

Oliver

Am 05.01.2013 16:48, schrieb Oliver Heger:

Hi Jörg,

Am 04.01.2013 17:47, schrieb Jörg Schaible:

Hi Oliver,

Oliver Heger wrote:


Hi,

recently I have worked on code regarding the creation of Configuration
objects and reloading support. I have created two Jira tickets [1, 2]
with a description of the problems I see in the current design.

The code in SVN (mainly in the new builder package) should be sufficient
to get a good impression about the direction I would like to go. It is
far more than a pure proof of concept.

However, following this road means some significant changes in the
design and in the way client code uses our classes. Therefore, I would
really appreciate feedback from other committers also interested in this
component.

My main question is: Can we replace the reloading mechanisms available
in 1.x by an approach based on builders as currently implemented in
trunk (e.g. classes
o.a.c.c.builder.ReloadingFileBasedConfigurationBuilder,
o.a.c.c.reloading.ReloadingController)? If the answer is 'yes', we could
go forward and significantly simplify most of the file-based
configuration implementations.

Thanks
Oliver

[1] https://issues.apache.org/jira/browse/CONFIGURATION-519
[2] https://issues.apache.org/jira/browse/CONFIGURATION-520


simply go-on with these changes. IMHO it looks good and since
separation of
concern leads here to significant code simplification, it's for the
best of
us devs and also for our users in the long term. Especially since the new
approach brings also improved functionality.


Thanks for your feedback. Will do!

Oliver



Cheers,
Jörg


-
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: svn commit: r1443696 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java

2013-02-08 Thread Oliver Heger


Am 08.02.2013 09:26, schrieb Benedikt Ritter:

Hi Simo,


2013/2/8 Simone Tripodi 


How do you feel about this? Checkstyle complains about this, and I think

it

is sufficient to tell users that an argument must not be null.


sorry, which one?



should have made that clearer :)
I removed the @throws NullpointerException from the JavaDoc because check
style complains about this (NPE is not declared in the method's signature).
I think it is enough to tell users that an argument must not be null. WDYT?

Benedikt


In his "Effective Java" Josh Bloch recommends the following related to 
runtime exceptions:

- Don't declare them using a throws clause
- Document them in JavaDocs using @throws

In [configuration] I do it this way. I am wondering why checkstyle 
complains about the Javadocs declaration. Maybe its configuration should 
be tweaked?


Oliver






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: [functor] Change default arity of Function, Predicate and Procedure

2013-02-14 Thread Oliver Heger


Am 14.02.2013 16:51, schrieb Matt Benson:

I would say that certainly one would often want to create an API like
you've described.  What I am reluctant not to support is:

class Foo {
   static void add(Argumented> functor);
}

Foo.add(new BinaryFunction() {});
Foo.add(new BinaryProcedure() {});
Foo.add(new BinaryPredicate() {});

The arguments are alike in their "argumentedness" while having different
functional interfaces.  Convince me this can never be useful, and we can
drop the whole thing ;P

Matt


Scala seems to use a similar approach: There are traits (a trait is 
something like a more advanced interface in Java) like Function1, 
Function2, ... with type parameters for the argument types and the 
result type.


The nice thing in Scala is that its syntax allows you to write function 
literals in a pretty comprehensive form. The compiler maps this 
automatically to the corresponding FunctionX trait.


Oliver




On Thu, Feb 14, 2013 at 8:55 AM, Jörg Schaible
wrote:


Hi Matt,

Matt Benson wrote:


Once again, an enum wouldn't readily be able to contribute to your
functor's being able to participate in some method by type signature;
i.e., I want to support the use case of:

add(Argumented somethingThatTakesTwoArguments);

Maybe this isn't a worthwhile goal, but so far I don't see anything else
that accomplishes this.


In any case, I wonder if we really want to support type safety for the
argument *types* themselves.

[snip]



interface Arity {
}

interface Argumented {
}

interface Unary extends Arity {
}

interface UnaryFunction extends Argumented> {
}



This is more complicated then having the functors extend Arity, but

it

makes better use of inheritance from an OO POV I think.

Just to make sure I understand correctly: If I had an UnaryFunction
that take a Boolean argument and return an Integer I would model this
as: class MyFunction implements UnaryFunction,
right?


  class Foo {
  static CharSequence add(UnaryFunction f);
  }

  Foo.add(new UnaryFunction(){});
  Foo.add(new UnaryFunction(){});
  Foo.add(new UnaryFunction(){});


This could get really nasty to use.

- Jörg


-
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: [BeanUtils] Plans for BeanUtils and BeanUtils2

2013-02-20 Thread Oliver Heger


Am 20.02.2013 16:25, schrieb Benedikt Ritter:

Hi Jörg


2013/2/20 Jörg Schaible 


Hi Benedikt,

Benedikt Ritter wrote:


Hi,

I'd like to discuss how the development of [BeanUtils] and [BeanUtils2]
can be continued.

The last release of BeanUtils (1.8.3) is now nearly 3 years ago and there
are 92 open issues in JIRA.
OTOH we've put quiet some effort into [BeanUtils2]. There are some issues
that have to be addressed* but the API is in a good shape.
But [BeanUtils2] is also a complete redesign of the API that is binary
incompatible with [BeanUtils].

Keeping this in mind I propose the following:
- promote [BeanUtils2] to proper; move it to a 2.0 branch in the

beanutils

svn subtree.**
- fix all issues that can be fixed without breaking BC in [BeanUtils] to
push out a last bug fix release for users that don't want to swtich to a
new API.
- Make clear that BeanUtils 1.8.4 will be the last release of  the 1.x
line.

WDYT?


Sounds perfectly reasonable. If you have only maintenance stuff 1.8.4 is
fine. If you intent to add new features for the 1.x line, you might better
call it 1.9.0 after all this years.



Okay, I'll try to review the open issues this weekend.



I am also interested in a new BeanUtils release and would like to 
contribute some new features. Unfortunately, I am not sure when I get 
the cycles to work on this.


Oliver







Benedikt

* Some JavaDoc is still missing and we have to take a look at the

caching.

AFAIK WeakHashMap is not the best choice for an in-memory-cache. We'll
discuss this in a separate thread.
** I don't know the exact formal process for this. What has to be done to
promote a component to proper? Does there have to be a formal vote by the
PMC?


Not sure for this special case either. Actually you're not promoting a new
component. However, you may look into the archives, IIRC Simo had the same
case for the last major release of digester.



I'll ask Simo what he has done for digister.

Thanks a lot!
Benedikt




Cheers,
Jörg


-
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: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF

2013-02-20 Thread Oliver Heger


Am 20.02.2013 16:42, schrieb t...@apache.org:

Author: tn
Date: Wed Feb 20 15:42:09 2013
New Revision: 1448251

URL: http://svn.apache.org/r1448251
Log:
Update version info

Modified:
 commons/proper/logging/trunk/src/conf/MANIFEST.MF

Modified: commons/proper/logging/trunk/src/conf/MANIFEST.MF
URL: 
http://svn.apache.org/viewvc/commons/proper/logging/trunk/src/conf/MANIFEST.MF?rev=1448251&r1=1448250&r2=1448251&view=diff
==
--- commons/proper/logging/trunk/src/conf/MANIFEST.MF (original)
+++ commons/proper/logging/trunk/src/conf/MANIFEST.MF Wed Feb 20 15:42:09 2013
@@ -5,4 +5,4 @@ Specification-Version: 1.0
  Implementation-Title: Commons Logging
  Implementation-Vendor-Id: org.apache
  Implementation-Vendor: Apache Software Foundation
-Implementation-Version: 1.1.1
+Implementation-Version: 1.1.2


Just wondering whether this is necessary. Doesn't the maven build 
automatically generate a fully configured MANIFEST including OSGi meta data?


Oliver

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

Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF

2013-02-22 Thread Oliver Heger


Am 22.02.2013 17:43, schrieb Thomas Neidhart:

On 02/22/2013 05:35 PM, Thomas Neidhart wrote:

On 02/22/2013 05:09 PM, Thomas Neidhart wrote:

On 02/20/2013 09:48 PM, Jörg Schaible wrote:

Hi Thomas,

Thomas Neidhart wrote:


On 02/20/2013 09:33 PM, Oliver Heger wrote:

Am 20.02.2013 16:42, schrieb t...@apache.org:

Author: tn
Date: Wed Feb 20 15:42:09 2013
New Revision: 1448251

URL: http://svn.apache.org/r1448251
Log:
Update version info

Modified:
  commons/proper/logging/trunk/src/conf/MANIFEST.MF

Modified: commons/proper/logging/trunk/src/conf/MANIFEST.MF
URL:


http://svn.apache.org/viewvc/commons/proper/logging/trunk/src/conf/MANIFEST.MF?rev=1448251&r1=1448250&r2=1448251&view=diff




==


--- commons/proper/logging/trunk/src/conf/MANIFEST.MF (original)
+++ commons/proper/logging/trunk/src/conf/MANIFEST.MF Wed Feb 20
15:42:09 2013
@@ -5,4 +5,4 @@ Specification-Version: 1.0
   Implementation-Title: Commons Logging
   Implementation-Vendor-Id: org.apache
   Implementation-Vendor: Apache Software Foundation
-Implementation-Version: 1.1.1
+Implementation-Version: 1.1.2



Just wondering whether this is necessary. Doesn't the maven build
automatically generate a fully configured MANIFEST including OSGi meta
data?


wondered about exactly the same.



yes, but somehow the ant build script is still in use (e.g. for gump)
and both ant & maven refer to this hard-coded manifest.


If Gump uses Ant here, this is just for historical reasons. Gump can use
Maven since quite some time now.


Ok, when I try to remove the hard-coded manifest, the
maven-bundle-plugin steps in and automatically creates one.

This is fine, but the Import-Package contains all (optional)
dependencies which are not marked like that.

I am not so familiar with these things, does somebody know how to
specify this?

Or would this not work at all, as already outlined in LOGGING-124?


After some research, I started with this:

   
 org.apache.felix
 maven-bundle-plugin
 true
 
   
 *;resolution:=optional
 *
   
 
   

All dependencies are optional, so this should be fine.
I added the DynamicImport but this may be to generic, and has to be
limited to the actual packages that are loaded dynamically by the
discovery process.

Can anybody provide me with a simple test bundle to see if logging would
work when loaded in e.g. apache felix?


Well, I have not yet a clue about osgi, and I see that felix has
re-bundled commons-logging in a total different way:

http://svn.apache.org/repos/asf/felix/trunk/commons/commons-logging/pom.xml


It is said that the maven-bundle-plugin could determine optional 
dependencies automatically based on optional attributes in the maven 
dependencies. However, when I tried this the last time - about half a 
year ago - I could not get this to work.


The pom for [configuration] can be used as an example for an alternative 
approach. It declares a number of optional dependencies explicitly. This 
is done by setting the commons.osgi.import property (which is evaluated 
by the configuration of the maven-bundle-plugin inherited from the 
parent pom).


Oliver



Thomas

-
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: [BeanUtils] Plans for BeanUtils and BeanUtils2

2013-02-22 Thread Oliver Heger


Hi Benedikt,

Am 21.02.2013 20:14, schrieb Benedikt Ritter:

Hi,


2013/2/20 Oliver Heger 


Am 20.02.2013 16:25, schrieb Benedikt Ritter:

  Hi Jörg



2013/2/20 Jörg Schaible 

  Hi Benedikt,


Benedikt Ritter wrote:

  Hi,


I'd like to discuss how the development of [BeanUtils] and [BeanUtils2]
can be continued.

The last release of BeanUtils (1.8.3) is now nearly 3 years ago and
there
are 92 open issues in JIRA.
OTOH we've put quiet some effort into [BeanUtils2]. There are some
issues
that have to be addressed* but the API is in a good shape.
But [BeanUtils2] is also a complete redesign of the API that is binary
incompatible with [BeanUtils].

Keeping this in mind I propose the following:
- promote [BeanUtils2] to proper; move it to a 2.0 branch in the


beanutils


svn subtree.**
- fix all issues that can be fixed without breaking BC in [BeanUtils] to
push out a last bug fix release for users that don't want to swtich to a
new API.
- Make clear that BeanUtils 1.8.4 will be the last release of  the 1.x
line.

WDYT?



Sounds perfectly reasonable. If you have only maintenance stuff 1.8.4 is
fine. If you intent to add new features for the 1.x line, you might
better
call it 1.9.0 after all this years.



Okay, I'll try to review the open issues this weekend.



I am also interested in a new BeanUtils release and would like to
contribute some new features. Unfortunately, I am not sure when I get the
cycles to work on this.



Nice to hear this. I'm starting tonight by sorting the open issues into can
"be fixed in 1.8.4" and "has to be fixed later".
IIRC you need new features for [configuration], right? Can you create
issues for this, if you don't already have?


two issues were created.

Oliver



TIA!
Benedikt





Oliver








Benedikt

* Some JavaDoc is still missing and we have to take a look at the


caching.


AFAIK WeakHashMap is not the best choice for an in-memory-cache. We'll
discuss this in a separate thread.
** I don't know the exact formal process for this. What has to be done
to
promote a component to proper? Does there have to be a formal vote by
the
PMC?



Not sure for this special case either. Actually you're not promoting a
new
component. However, you may look into the archives, IIRC Simo had the
same
case for the last major release of digester.



I'll ask Simo what he has done for digister.

Thanks a lot!
Benedikt




Cheers,
Jörg


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








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








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

Re: [VOTE] Release of Commons Email 1.3.1 based on RC2

2013-02-24 Thread Oliver Heger

Build and site generation run fine on Windows 7 with Java 1.5 and 1.7. 
Artifacts and site look good.


+1

Oliver

Am 24.02.2013 18:54, schrieb Thomas Neidhart:

Hi,

I'd like to call a vote for releasing Commons Email 1.3.1 based on RC2.

This release candidate has the following changes compared to RC1:

* Clirr compares now to 1.3 rather than 1.2
* Link to released API has been fixed

The files:

The artifacts are deployed to Nexus:
https://repository.apache.org/content/repositories/orgapachecommons-298/org/apache/commons/commons-email/1.3.1/

The tag:
https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_1_RC2/

The site:
http://people.apache.org/builds/commons/email/1.3.1/RC2/

Additional Notes:

o the download page and api links to older releases only work on
   the published site and will be corrected after release.

Please take a look at the commons-email-1.3.1 artifacts and vote!


[ ] +1 release it.
[ ] +0 go ahead; I don't care.
[ ] -0 there are a few minor glitches: ...
[ ] -1 no, do not release it because ...


Vote will remain open for at least 72 hours.

Thanks in advance,

Thomas

-
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: [BeanUtils] Next release 1.8.4 or 1.9?

2013-02-28 Thread Oliver Heger


Hi,

Am 28.02.2013 14:28, schrieb Benedikt Ritter:

2013/2/23 Benedikt Ritter 


Hi,

I just wanted to start a discussion whether we should push out a bugfix
release or start to work on new features right away and release a 1.9
(including bug fixes of course ;-)

Benedikt



I have looked through a lot of issues in the meantime. There are currently
at least 11 bugs that could be fixed in 1.8.4. So IMHO it makes sense to
push out a 1.8.4 and start working on new features afterwards.
I'd like to hear Olivers thoughts about this, as I think he needs new
features for the next [configuration] release.


I started working on a patch for BEANUTILS-425, so I hope to get this in 
in near future. This is what I would need for a new [configuration] 
release. However, before this can happen, there are lots of things to 
do. So no need to hurry.


That said, I think it is a valid option to skip the maintenance release 
and go directly to the feature release, even if this takes a little 
longer. (The last release was long ago, so a few weeks/months do not 
make a difference.)


But if you have free time available and want to go ahead, just do it.

Oliver



Benedikt




--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter








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

Re: [VOTE] Release of Commons Email 1.3.1 based on RC3

2013-02-28 Thread Oliver Heger

+1, looks good.

Just one minor thing: The source release now contains the cgi for the
download page. Is this expected to be there? I did not notice it before,
but the RAT report was complaining about it. This was not the case for
the previous RC.

Oliver

Am 27.02.2013 22:37, schrieb Thomas Neidhart:

Hi,

I'd like to call a vote for releasing Commons Email 1.3.1 based on RC3.

This release candidate has the following changes compared to RC2:

* Added missing slf4j binding which caused test failures with IBM JDKs

The files:

The artifacts are deployed to Nexus:
https://repository.apache.org/content/repositories/orgapachecommons-313/org/apache/commons/commons-email/1.3.1/

The tag:
https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_1_RC3/

The site:
http://people.apache.org/builds/commons/email/1.3.1/RC3/

Additional Notes:

o the download page and api links to older releases only work on
the published site and will be corrected after release.

Please take a look at the commons-email-1.3.1 artifacts and vote!

[ ] +1 release it.
[ ] +0 go ahead; I don't care.
[ ] -0 there are a few minor glitches: ...
[ ] -1 no, do not release it because ...

Vote will remain open for at least 72 hours.

Thanks in advance,

Thomas

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

Re: [BeanUtils] Next release 1.8.4 or 1.9?

2013-03-01 Thread Oliver Heger


Am 01.03.2013 09:20, schrieb Benedikt Ritter:

Hi Oliver,


2013/2/28 Oliver Heger 


Hi,

Am 28.02.2013 14:28, schrieb Benedikt Ritter:

  2013/2/23 Benedikt Ritter 


  Hi,


I just wanted to start a discussion whether we should push out a bugfix
release or start to work on new features right away and release a 1.9
(including bug fixes of course ;-)

Benedikt



I have looked through a lot of issues in the meantime. There are currently
at least 11 bugs that could be fixed in 1.8.4. So IMHO it makes sense to
push out a 1.8.4 and start working on new features afterwards.
I'd like to hear Olivers thoughts about this, as I think he needs new
features for the next [configuration] release.



I started working on a patch for BEANUTILS-425, so I hope to get this in
in near future. This is what I would need for a new [configuration]
release. However, before this can happen, there are lots of things to do.
So no need to hurry.



Didn't know that you're already working on that. Can you assign the issue
to yourself?



That said, I think it is a valid option to skip the maintenance release
and go directly to the feature release, even if this takes a little longer.
(The last release was long ago, so a few weeks/months do not make a
difference.)

But if you have free time available and want to go ahead, just do it.



No, you're probably right, a few month more make no difference and I'd
really like to work on BEANUTILS-406 [1]. I don't know which impact the
decision to do a 1.9 next has on Jira (fix versions etc.). Can you do the
necessary changes?
I think until we make a final decision and start with release 
preparations there is no need to update Jira properties. When time 
comes, it is possible to do some batch updates to change fix versions 
for all affected issues.


Oliver



Benedikt

[1] https://issues.apache.org/jira/browse/BEANUTILS-406




Oliver




Benedikt




--
http://people.apache.org/~**britter/<http://people.apache.org/~britter/>
http://www.systemoutprintln.**de/ <http://www.systemoutprintln.de/>
http://twitter.com/**BenediktRitter <http://twitter.com/BenediktRitter>
http://github.com/britter








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








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

Re: [ALL] Adding Projects to ASF git mirrors

2013-03-01 Thread Oliver Heger


Am 01.03.2013 09:22, schrieb Luc Maisonobe:

Hi Benedikt,

Le 01/03/2013 09:14, Benedikt Ritter a écrit :

Nobody seems to know (or to care ;-), so I'll wait until 72 hours have
passed. If nobody objects until after 72 hours have passed, I'll file an
issue for INFRA.


As far as I know, there are no specific decisions about Git mirrors.
There are already a few of them for some of our components, and they
could even been requested by almost anybody.


I saw that many components are already available through git and added a 
ticket to make [configuration] available some days ago.


Oliver



Luc



Benedikt


2013/2/27 Benedikt Ritter 


Hi,

there is an issue to create a git mirror of BeanUtils [1]. This seems to
be as easy as creating an issue for INFRA [2]. I just wanted to ask if
there has to be some sort of formal decision (from the PMC) before a git
mirror can be requested.

If not I'd like to take care of this.

Thanks,
Benedikt

[1] https://issues.apache.org/jira/browse/BEANUTILS-404
[2] http://www.apache.org/dev/git.html


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter








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




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

Re: [ALL] "current" links in download directories

2013-03-04 Thread Oliver Heger


Am 04.03.2013 20:36, schrieb Gary Gregory:

Delete them.


+1

IIRC, it was part of older release instructions to create such links. 
The instructions have been updated, but probably after the last Digester 
release.


Oliver



Gary


On Mon, Mar 4, 2013 at 2:34 PM, sebb  wrote:


Some components have "current" links in the top-level dist/ directories.

For example:

http://www.apache.org/dist/commons/digester/

has several such links.

These are presumably supposed to always point to the current latest
release.
However, they are tricky to maintain (perhaps more so now we are
moving to svnpubsub).

Also they don't behave well. For example, if one downloads the link,
the file is named after the link, not the target, so it's not clear
exactly what has been downloaded. Also one cannot tell what file is
being referenced.

In fact, looking at the files uploaded to

https://dist.apache.org/repos/dist/release/commons/digester/

it appears that the entries are copies of the files, not actually
links, so the links clearly are tricky to maintain. Also there are now
two copies of each of the files in SVN, and these will appear on each
3rd party mirror. Not ideal.

The links are expensive in maintenance and disk space.

I think they should be deleted unless there is a very good use-case
for keeping them.  This seems very unlikely, as no-one has complained
about the Commons components that don't have the links.

Thoughts?

-
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: [BeanUtils] Update to Java 1.5 for next release?

2013-03-06 Thread Oliver Heger


Am 06.03.2013 13:35, schrieb sebb:

On 6 March 2013 11:32, Benedikt Ritter  wrote:

Hi,

I have recently learned that changing the required Java version for a
component does not necessarily affect binary compartibility [1].
I'm thinking about updating [BeanUtils] to Java 1.5. We would have the
following advantages:

- concurrency facilities in java.util.concurrent (could be useful for the
internal caching)
- generics
- JUnit 4

WDYT?


+1


+1 from me, too. It really felt strange when creating patches to adhere 
to Java 1.3 restrictions.


Oliver




Benedikt


[1] http://markmail.org/message/mgsjqib5iyyaicgg
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter


-
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: [BeanUtils][RTC] BEANUTILS-422 - getPropertyType return null on second descendant class

2013-03-14 Thread Oliver Heger


Am 14.03.2013 08:42, schrieb Benedikt Ritter:

2013/3/10 Benedikt Ritter 


Hi,

we have this bug filed for BeanUtils, that seems to be related to generic
collections used for indexed properties in conjunction with Java 7. In
summary, when using a List instead of a untyped List for an indexed
property, PropertyUtils.getPropertyType will return null.

There is a proposed solution for this problem that basically flushes the
cache of Introspector and reloads the property descriptors afterwards. It
works, but it looks like a lot of additional reloading. I'm wondering if
anybody has another idea how to work around this issue.



ping,

would be nice to have some comments. If nobody has the time right now, I'll
post pone this issue :-)


Do we have any idea what actually happens? In which way has 
introspection changed in the affected JDK 1.7 versions?


Maybe there is something interesting in the release notes. Or it could 
make sense checking the Java Bug database?


Oliver



Regards,
Benedikt




TIA,
Benedikt


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter








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

Re: [VOTE] Release of Commons Logging 1.1.2 based on RC2

2013-03-16 Thread Oliver Heger

Build works fine on Windows 7 with Java 1.5 and 1.7, artifacts and site
look good.

One thing I noticed, not sure whether this is actually a problem: The
artifacts for adapters and api have the same manifest information as the
main jar. Are they intended to be used in an OSGi environment? Could
this cause problems?

Oliver

Am 16.03.2013 14:06, schrieb Thomas Neidhart:

Hi,

I'd like to call a vote for releasing Commons Logging 1.1.2 based on RC2.

This release candidate has the following changes compared to RC1:

* Fix deployment process to include also missing bin/src assemblies
* Disable reference release test for WeakHashtable as it was unreliable
on various JVMs
* Fix several unit tests related to security permissions when run with
IBM JVM 6

The files:

The artifacts are deployed to Nexus:
https://repository.apache.org/content/repositories/orgapachecommons-007/commons-logging/commons-logging/1.1.2/

The tag:
https://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_2_RC2/

The site:
http://people.apache.org/builds/commons/logging/1.1.2/RC2/

Additional Notes:

o the download page and api links to older releases only work on
the published site and will be corrected after release.

Please take a look at the commons-logging-1.1.2 artifacts and vote!

[ ] +1 release it.
[ ] +0 go ahead; I don't care.
[ ] -0 there are a few minor glitches: ...
[ ] -1 no, do not release it because ...

Vote will remain open for at least 72 hours.

Thanks in advance,

Thomas

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

Re: [LOGGING] OSGi Meta data is the same for adapters and api jar Was: [VOTE] Release of Commons Logging 1.1.2 based on RC2

2013-03-18 Thread Oliver Heger

Am 16.03.2013 19:43, schrieb Benedikt Ritter:

Hi Oliver

2013/3/16 Oliver Heger

Build works fine on Windows 7 with Java 1.5 and 1.7, artifacts and site
look good.

Logging can not be used without additional setup in an OSGi environment.
This is for "historical" reasons. The library was not designed with OSGi in
mind and making it OSGi ready would require to change packaging. Have a
look LOGGING-124 [1] for more information about this. I have tried to sum
up what we have learned about [logging] and OSGi in the wiki (see bottom of
[2]). Feel free to comment or add something :)

Hm, I have difficulties with understanding both your statement and the
WIKI documentation. IIUC, you basically say that OSGi meta data does not
really matter because [logging] does not work in an OSGi environment
anyway. Wouldn't it then be better to drop it completely?

The WIKI says, it is "difficult to get commons-logging working in OSGi
environments". This is not really helpful. If it is possible to make it
work with OSGi, it should be described how this is done. Otherwise, it
should be clearly stated.

Oliver

Regards,
Benedikt

[1] https://issues.apache.org/jira/browse/LOGGING-124
[2] http://wiki.apache.org/commons/Logging/FrequentlyAskedQuestions

Oliver

Am 16.03.2013 14:06, schrieb Thomas Neidhart:

Hi,

I'd like to call a vote for releasing Commons Logging 1.1.2 based on RC2.

This release candidate has the following changes compared to RC1:

The files:

The artifacts are deployed to Nexus:
https://repository.apache.org/**content/repositories/**
orgapachecommons-007/commons-**logging/commons-logging/1.1.2/<https://repository.apache.org/content/repositories/orgapachecommons-007/commons-logging/commons-logging/1.1.2/>

The tag:
https://svn.apache.org/repos/**asf/commons/proper/logging/**
tags/LOGGING_1_1_2_RC2/<https://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_2_RC2/>

The site:
http://people.apache.org/**builds/commons/logging/1.1.2/**RC2/<http://people.apache.org/builds/commons/logging/1.1.2/RC2/>

Additional Notes:

o the download page and api links to older releases only work on
the published site and will be corrected after release.

Please take a look at the commons-logging-1.1.2 artifacts and vote!

--**--
[ ] +1 release it.
[ ] +0 go ahead; I don't care.
[ ] -0 there are a few minor glitches: ...
[ ] -1 no, do not release it because ...
--**--

Vote will remain open for at least 72 hours.

Thanks in advance,

Thomas

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

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

Re: [VOTE] Release of Commons Logging 1.1.2 based on RC2

2013-03-18 Thread Oliver Heger

As I understand it, this release does not change anything regarding OSGi
compatibility of [logging], and therefore OSGi meta data does not seem
to be a problem.

So +1.

Oliver

Am 16.03.2013 19:14, schrieb Oliver Heger:

Build works fine on Windows 7 with Java 1.5 and 1.7, artifacts and site
look good.

Oliver

Am 16.03.2013 14:06, schrieb Thomas Neidhart:

Hi,

I'd like to call a vote for releasing Commons Logging 1.1.2 based on RC2.

This release candidate has the following changes compared to RC1:

The files:

The artifacts are deployed to Nexus:
https://repository.apache.org/content/repositories/orgapachecommons-007/commons-logging/commons-logging/1.1.2/

The tag:
https://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_2_RC2/

The site:
http://people.apache.org/builds/commons/logging/1.1.2/RC2/

Additional Notes:

o the download page and api links to older releases only work on
the published site and will be corrected after release.

Please take a look at the commons-logging-1.1.2 artifacts and vote!

[ ] +1 release it.
[ ] +0 go ahead; I don't care.
[ ] -0 there are a few minor glitches: ...
[ ] -1 no, do not release it because ...

Vote will remain open for at least 72 hours.

Thanks in advance,

Thomas

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

Re: [FILEUPLOAD] Package protected classes have public methods - make these package protected?

2013-03-19 Thread Oliver Heger


Am 18.03.2013 11:19, schrieb sebb:

On 18 March 2013 10:07, Benedikt Ritter  wrote:

2013/3/18 sebb 


The new utils.mime classes for MIME decoding are mostly package-protected.

However, they have public methods (and ctors) which is a bit misleading.

I think it would make sense to reduce the visibility to package protected.

Any objections?



I personally don't align visibility of methods to the defining classes
visibility. If you decide to change the classes visibility to public you
will have to go though all methods and change method visibility too...


Well yes, of course.
But these classes are specifically for internal use only.

Also I think objects should be created with the minimum visibility required.
If it turns out more visibility is needed, it can be changed without
causing incompatibility.
Reducing visibility after release is not so easy.



Sorry, I disagree here. The classes affected are not part of the public 
API, so the argument of reducing visibility does not hold.


OTOH, different visibility of methods is a hint which methods are 
expected to be called from outside and which are internal helper methods.


Oliver



Benedikt




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





--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter


-
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 Math 3.2 - RC4

2013-04-01 Thread Oliver Heger

Artifacts and site look good. When building with Java 1.5 under Windows 
7, I get the output below. A build with Java 1.7 is successful.


IIRC I had similar results for the last release with JDK 1.5. So I 
assume this is not a blocker, and here is my +1


Oliver


Failed tests:
  GammaDistributionTest.testMath753Shape142:351->doTestMath753:298 
shape = 142.0

, scale = 1.0
Old implementation
--
SummaryStatistics:
n: 463
min: 0.0
max: 553.0
mean: 384.3887688984882
geometric mean: 0.0
variance: 9958.419960169416
sum of squares: 7.3011228E7
standard deviation: 99.79188323791378
sum of logs: -Infinity
New implementation
--
SummaryStatistics:
n: 463
min: 0.0
max: 26.0
mean: 2.460043196544277
geometric mean: 0.0
variance: 2.2013220760520977
sum of squares: 3819.0
standard deviation: 1.483685302229586
sum of logs: -Infinity


FastMathStrictComparisonTest.test1:88->setupMethodCall:192->callMethods:167->r
eportFailedResults:154 double toRadians(-4.9E-324) expected -0.0 actual 
0.0 entr

ies [12]

Tests run: 4974, Failures: 2, Errors: 0, Skipped: 45

Am 30.03.2013 23:54, schrieb Luc Maisonobe:

This is a [VOTE] for releasing Apache Commons Math 3.2, based on release
candidate 4.

This version fixes numerous bugs and adds a few features.

You can retrieve the various parts here:

Sources, binaries and release notes:

 (svn revision 1688)

Maven artifacts are here:



Details of changes since 3.1.1 are in the release notes:





Tag (this time with the correct URL...):


(svn revision 1462820)

Site:



All reports (CLIRR, RAT, findbugs ...) :



Note that the PMD report shows several violations. A few of them are
false positive (unused method, unused field). A number of them are
voluntary (overriding method that simply calls super) because what we
really need in these cases is to add specific javadoc in the overriding
method. The remaining errors correspond to unused parameters. They are
known and correspond to deprecated method that will be removed in 4.0.
So despite the report is not perfectly clean, in fact everything that
could be fixed in it has already been fixed.

Votes, please.
This vote will close in 72 hours: 2013-04-02T23:00:00 UTC

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

   Thanks!

Luc


-
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 Math 3.2 - RC5

2013-04-03 Thread Oliver Heger

Same results as for the last RC, i.e. I see two test failures when 
building with Java 1.5, but the build with Java 1.7 succeeds.


+1

One very minor nit: In the release notes, there are some not so nice 
line breaks which make reading with a plain text editor harder as necessary.


Oliver

Am 02.04.2013 22:55, schrieb Luc Maisonobe:

This is a [VOTE] for releasing Apache Commons Math 3.2, based on release
candidate 5.

This version fixes numerous bugs and adds a few features.

You can retrieve the various parts here:

Sources, binaries and release notes:

 (svn revision 1728)

Maven artifacts are here:



Details of changes since 3.1.1 are in the release notes:




(will be available only tomorrow morning European time)

Tag:


(svn revision 1463704)

Site (will be available only tomorrow morning European time):



All reports (CLIRR, RAT, findbugs ...) :


  (will be available only tomorrow morning European time)

Note that the PMD report shows several violations. A few of them are
false positive (unused method, unused field). A number of them are
voluntary (overriding method that simply calls super) because what we
really need in these cases is to add specific javadoc in the overriding
method. The remaining errors correspond to unused parameters. They are
known and correspond to deprecated method that will be removed in 4.0.
So despite the report is not perfectly clean, in fact everything that
could be fixed in it has already been fixed.

Votes, please.
This vote will close in 72 hours: 2013-04-05T21:00:00 UTC

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

   Thanks!

Luc


-
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: [CSV] Should the Builder API be optional?

2013-04-10 Thread Oliver Heger


Am 09.04.2013 08:48, schrieb Benedikt Ritter:

2013/4/8 Emmanuel Bourg 


Le 08/04/2013 22:39, Gary Gregory a écrit :


But that's the price for immutability for some of these objects.


Not sure, we already achieved immutability last year without paying this
price:


http://svn.apache.org/repos/asf/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?p=1305548

This design was sacrified for the sake of implementing a "by the book"
builder pattern that brings no real benefit in term of usability. It's
just a useless layer of complexity.



You're right, the old impl was already immutable. The problem was, that it
was not possible for a CSVFormat to validate itself at construction time.
We had to call the package private validate() method. I think we have been
through this several times. All arguments have been exchanged. If there is
a way to let a CSVFormat validate itself by the time it is constructed with
the old AP, I'm more than happy to drop the builder.

This is not about implementing "by the book" builder patterns.


Not sure whether this is worth the effort, but maybe as an academic 
exercise in defining DSLs with Java:


Would an approach like the following one be acceptable from an API 
user's point of view:


CSVFormat newFormat = CSVFormat.DEFAULT.derive(
  withDelimiter('!'), withNullString("NULL"));

Here the derive() method expects a number of FormatManipulator objects 
as varargs argument. The withXXX() methods are static methods either in 
CSVFormat or a separate helper class creating concrete FormatManipulator 
implementations.


derive() creates a mutable format definition object based on its current 
state. It iterates over its arguments passing each the format definition 
object. Concrete manipulator implementations update it accordingly. At 
the end, the resulting format definition is validated, and a new 
immutable CSVFormat is created from it.


This is obviously some implementation effort. It requires less code for 
the user of the API. The approach is extensible, new properties can be 
added by providing new manipulator implementations and static 
convenience methods for creating them.


Oliver



Benedikt





Emmanuel Bourg









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

Re: [VOTE] Release Commons Codec 1.8-RC3

2013-04-18 Thread Oliver Heger

Artifacts and site look good, building the jar was successful with Java 
7 on Windows, however I could not build the site locally because pmd.xml 
is missing:


[INFO] BUILD FAILURE
[INFO] 


[INFO] Total time: 5:06.882s
[INFO] Finished at: Thu Apr 18 21:47:10 CEST 2013
[INFO] Final Memory: 43M/114M
[INFO] 

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.2:si
te (default-cli) on project commons-codec: Error during page generation: 
Error r
endering Maven report: Could not find resource 
'D:\data\projects\OpenSource\code

c\commons-codec-1.8-src/pmd.xml'. -> [Help 1]

(This file is also reported by RAT as having no license header.)

Oliver

Am 18.04.2013 15:54, schrieb Gary Gregory:

Hello All:

This is a VOTE to release Commons Codec 1.8-RC3.

Commons Codec 1.8 requires a minimum of Java 1.6

Changes from 1.8-RC2 are:

Clarify NOTICE.txt

Changes from 1.8-RC1 are:

o Set the correct version for the Ant build in default.properties
o Fix URLs in NOTICE.txt file and Java source for ASpell.

Changes in this version include:

New features:
o CODEC-168:  Add DigestUtils.updateDigest(MessageDigest, InputStream).
Thanks to Daniel Cassidy.
o CODEC-167:  Add JUnit to test our decode with pad character in the middle.
o CODEC-161:  Add Match Rating Approach (MRA) phonetic algorithm encoder.
Thanks to crice.

Fixed Bugs:
o CODEC-163:  ColognePhonetic encoder unnecessarily creates many char
arrays on every loop run. Thanks to leo141.
o CODEC-160:  Base64.encodeBase64URLSafeString doesn't add padding
characters at the end.

This VOTE is open for at least 72 hours until April 21 2013 at 10:00 AM EST.

The files:

https://repository.apache.org/content/repositories/orgapachecommons-113/

The tag:

https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.8-RC3

The site:

https://people.apache.org/~ggregory/commons-codec/1.8-RC3/site/

Thank you,
Gary Gregory




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

Re: [VOTE] Release Commons Codec 1.8-RC4

2013-04-19 Thread Oliver Heger


+1

Found no more problems.

Thanks, Gary!
Oliver

Am 19.04.2013 18:56, schrieb Gary Gregory:

Hello All:

This is a VOTE to release Commons Codec 1.8-RC4.

Commons Codec 1.8 requires a minimum of Java 1.6

Changes from 1.8-RC3 are:

Add pmd.xml to source distribution to build the site.

Changes from 1.8-RC2 are:

Clarify NOTICE.txt

Changes from 1.8-RC1 are:

o Set the correct version for the Ant build in default.properties
o Fix URLs in NOTICE.txt file and Java source for ASpell.

Changes in this version include:

New features:
o CODEC-168:  Add DigestUtils.updateDigest(MessageDigest, InputStream).
Thanks to Daniel Cassidy.
o CODEC-167:  Add JUnit to test our decode with pad character in the middle.
o CODEC-161:  Add Match Rating Approach (MRA) phonetic algorithm encoder.
Thanks to crice.

Fixed Bugs:
o CODEC-163:  ColognePhonetic encoder unnecessarily creates many char
arrays on every loop run. Thanks to leo141.
o CODEC-160:  Base64.encodeBase64URLSafeString doesn't add padding
characters at the end.

This VOTE is open for at least 72 hours until April 22 2013 at 1:00 PM EST.

The files:

https://repository.apache.org/content/repositories/orgapachecommons-121/

The tag:

https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.8-RC4

The site:

https://people.apache.org/~ggregory/commons-codec/1.8-RC4/site/

Thank you,
Gary Gregory




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

Re: [VOTE] Release Commons Codec 1.8-RC4 [Take 2]

2013-04-23 Thread Oliver Heger


Hi Gary,

I am very sorry that this happened to you. When I did my last release, I 
was pretty nervous when doing this manual deletion step. It would really 
be cool if this somehow could be automated.


Regarding the vote: I am not sure what exactly I have to check. This 
time the staging repository does not seem to contain the distribution 
archives. Is this intended?


Oliver

Am 23.04.2013 15:20, schrieb Gary Gregory:

Hello All:

This is a VOTE to release Commons Codec 1.8-RC4 (yes, /again/)

Commons Codec 1.8 requires a minimum of Java 1.6

Changes from 1.8-RC4 VOTE take 1 are:

NOTHING. I deleted too many checksum files in Nexus before trying to
release the repo, so I created a new staging repo:
https://repository.apache.org/content/repositories/orgapachecommons-129/

Changes from 1.8-RC3 are:

Add pmd.xml to source distribution to build the site.

Changes from 1.8-RC2 are:

Clarify NOTICE.txt

Changes from 1.8-RC1 are:

o Set the correct version for the Ant build in default.properties
o Fix URLs in NOTICE.txt file and Java source for ASpell.

Changes in this version include:

New features:
o CODEC-168:  Add DigestUtils.updateDigest(
MessageDigest, InputStream). Thanks to Daniel Cassidy.
o CODEC-167:  Add JUnit to test our decode with pad character in the middle.
o CODEC-161:  Add Match Rating Approach (MRA) phonetic algorithm encoder.
Thanks to crice.

Fixed Bugs:
o CODEC-163:  ColognePhonetic encoder unnecessarily creates many char
arrays on every loop run. Thanks to leo141.
o CODEC-160:  Base64.encodeBase64URLSafeString doesn't add padding
characters at the end.

This VOTE is open for at least 72 hours until April 22 2013 at 1:00 PM EST.

The files:

https://repository.apache.org/content/repositories/orgapachecommons-129/

The tag:

https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.8-RC4

The site:

https://people.apache.org/~ggregory/commons-codec/1.8-RC4/site/

Thank you,
Gary Gregory




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

Re: [VOTE] Release Commons Codec 1.8-RC4 [Take 3]

2013-04-25 Thread Oliver Heger


+1

Oliver

Am 23.04.2013 23:15, schrieb Gary Gregory:

On Apr 23, 2013, at 16:54, sebb  wrote:


On 23 April 2013 21:52, Gary Gregory  wrote:


Hello All:

This is a VOTE to release Commons Codec 1.8-RC4 (yes, sigh, /again/)

Commons Codec 1.8 requires a minimum of Java 1.6

Changes from 1.8-RC4 VOTE take 2 are:

NOTHING. In Nexus, I deleted the bin and src archive by mistake.

Changes from 1.8-RC4 VOTE take 1 are:

NOTHING. In Nexus, I deleted too many checksum files before trying to
release the repo, so I created a new staging repo:
https://repository.apache.org/content/repositories/orgapachecommons-129/

I think you mean:
https://repository.apache.org/content/repositories/orgapachecommons-130/


Yes, thank you.

Gary





Changes from 1.8-RC3 are:

Add pmd.xml to source distribution to build the site.

Changes from 1.8-RC2 are:

Clarify NOTICE.txt

Changes from 1.8-RC1 are:

o Set the correct version for the Ant build in default.properties
o Fix URLs in NOTICE.txt file and Java source for ASpell.

Changes in this version include:

New features:
o CODEC-168:  Add DigestUtils.updateDigest(
MessageDigest, InputStream). Thanks to Daniel Cassidy.
o CODEC-167:  Add JUnit to test our decode with pad character in the
middle.
o CODEC-161:  Add Match Rating Approach (MRA) phonetic algorithm encoder.
Thanks to crice.

Fixed Bugs:
o CODEC-163:  ColognePhonetic encoder unnecessarily creates many char
arrays on every loop run. Thanks to leo141.
o CODEC-160:  Base64.encodeBase64URLSafeString doesn't add padding
characters at the end.

This VOTE is open for at least 72 hours until April 26 2013 at 5:00 PM EST.

The files:

https://repository.apache.org/content/repositories/orgapachecommons-130/

The tag:

https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.8-RC4

The site:

https://people.apache.org/~ggregory/commons-codec/1.8-RC4/site/

Thank you,
Gary Gregory

--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition<
http://www.manning.com/bauer3/>
JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory



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




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

Re: [VOTE] Release Commons Codec 1.8-RC4 [Take 3]

2013-04-26 Thread Oliver Heger


Am 23.04.2013 23:15, schrieb Gary Gregory:

On Apr 23, 2013, at 16:54, sebb  wrote:


On 23 April 2013 21:52, Gary Gregory  wrote:


Hello All:

This is a VOTE to release Commons Codec 1.8-RC4 (yes, sigh, /again/)

Commons Codec 1.8 requires a minimum of Java 1.6

Changes from 1.8-RC4 VOTE take 2 are:

NOTHING. In Nexus, I deleted the bin and src archive by mistake.

Changes from 1.8-RC4 VOTE take 1 are:

NOTHING. In Nexus, I deleted too many checksum files before trying to
release the repo, so I created a new staging repo:
https://repository.apache.org/content/repositories/orgapachecommons-129/

I think you mean:
https://repository.apache.org/content/repositories/orgapachecommons-130/


Yes, thank you.

Gary


One proposal for future votes (at least until a final solution for the 
problems with unneeded checksums is found):


The artifacts not needed in Nexus should be removed before the vote. 
Then, after a successful vote, this error-prone step is already done, 
and the staging repository just has to be released.


Oliver







Changes from 1.8-RC3 are:

Add pmd.xml to source distribution to build the site.

Changes from 1.8-RC2 are:

Clarify NOTICE.txt

Changes from 1.8-RC1 are:

o Set the correct version for the Ant build in default.properties
o Fix URLs in NOTICE.txt file and Java source for ASpell.

Changes in this version include:

New features:
o CODEC-168:  Add DigestUtils.updateDigest(
MessageDigest, InputStream). Thanks to Daniel Cassidy.
o CODEC-167:  Add JUnit to test our decode with pad character in the
middle.
o CODEC-161:  Add Match Rating Approach (MRA) phonetic algorithm encoder.
Thanks to crice.

Fixed Bugs:
o CODEC-163:  ColognePhonetic encoder unnecessarily creates many char
arrays on every loop run. Thanks to leo141.
o CODEC-160:  Base64.encodeBase64URLSafeString doesn't add padding
characters at the end.

This VOTE is open for at least 72 hours until April 26 2013 at 5:00 PM EST.

The files:

https://repository.apache.org/content/repositories/orgapachecommons-130/

The tag:

https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.8-RC4

The site:

https://people.apache.org/~ggregory/commons-codec/1.8-RC4/site/

Thank you,
Gary Gregory

--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition<
http://www.manning.com/bauer3/>
JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory



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




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

Re: [collections] beta release - howto

2013-04-30 Thread Oliver Heger


Am 30.04.2013 17:17, schrieb Phil Steitz:

On 4/30/13 7:51 AM, Gilles wrote:

On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote:

On 4/29/13 11:49 PM, Thomas Vandahl wrote:

On 30.04.2013 00:01, Gilles wrote:

If someone doesn't develop a Commons component, he is not in the
"developer"
category for that component.
If his app _uses_ a Commons component, he is a "user" of that
component.
This kind of users should indeed be encouraged to test snapshots,
and
report
problems _before_ an official release is made.


I completely agree with you. Looking at the Commons components,
all "users" are also "developers" one way or another, as the
components are merley libraries, not applications.

 From what I understand of the Maven idea, snapshots are *the* way
binaries can be distributed for testing - including separate
storage in a separate repository. The whole repository
infrastructure was made for this. The snapshot status carries the
clear message that this binary is not for production use and can
change its API anytime. So why not use this?

The problem with "publicising" snapshots is that it makes it look
like they are actual releases.  This has been discussed a lot over
the years, and we have settled on the policy [1] that anything that
we encourage anyone beyond the developers actively following the dev
list ("developers" per the definition above), *must* be treated as a
release.

[1] http://www.apache.org/dev/release.html#what


Thanks for this clarification.

Unfortunately, the description of "release" does not provide a
solution
to the problem posed.
Essentially, it only forbids to ask for user feedback on
"unreleased" code.

The only way out is to release:
"If this policy seems inconvenient, then release more often."

But release what? "alpha", "beta"? Those are not defined there.


Projects are free to decide how to name and classify releases as
they see fit.  Some projects [1] classify releases as alpha, beta,
stable *after* they have been tested by users.  The *requirement* is
just that anything released and "publicised" via web site links,
announcements, etc. must go through the release process, as defined
by the PMC, meeting the minimum ASF requirements [2].


If such releases are done, then what policy wrt to user support?


Here again, this is up to the PMC to decide.  All that the ASF
mandates is that releases are properly vetted by the owning PMC and
meet the minimum requirements.


E.g. do we _have_ to (quickly) create bug fix releases for such
releases
(known to be more fragile)?

This looks much more complicated than just asking interested
parties to
"manually" download a nightly build (with all the caveats and
warnings),
temporarily add it to their classpath and look for unexpected
problems.


Should not be, really.  We are making good progress - thanks to you
and others - getting to an automated release process.  Cutting
alpha/beta releases including votes and compliance checks should not
be that hard and pushing the alpha/beta artifacts to snapshot (and /
or release) maven repos will make it easy for users to test.


+1 to going to the full release process.

But it is not yet clear to me for which kind of releases/version schemes 
changes on the public API are allowed. I mean, this is the purpose of 
the whole exercise: to gain feedback which may cause API changes before 
the final release is made.


Oliver



Phil

[1] http://tomcat.apache.org/whichversion.html
[2]
http://www.apache.org/dev/release.html#what-must-every-release-contain



Gilles


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





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




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

Re: [VOTE] Release of Commons Logging 1.1.3 based on RC2

2013-05-18 Thread Oliver Heger

Build works fine on Windows 7 with Java 1.5 and 1.7, artifacts and site
look good.

I am no OSGi expert, but I doubt that the different artifacts (main jar,
api, adapters) should all have the same meta data. However, this was
also the case in the previous release, so obviously not blocking.

Oliver

Am 16.05.2013 22:28, schrieb Thomas Neidhart:

Hi,

I'd like to call a vote for releasing Commons Logging 1.1.3 based on RC2.

This release candidate has the following changes compared to RC1:

* fix ant build script: version, dependencies, created artifacts

The files:

The artifacts are deployed to Nexus:
https://repository.apache.org/content/repositories/orgapachecommons-006/commons-logging/commons-logging/1.1.3/

Distribution files:
https://dist.apache.org/repos/dist/dev/commons/logging/

The tag:
https://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_3_RC2/

The site:
http://people.apache.org/builds/commons/logging/1.1.3/RC2/

Additional Notes:

o the download page and api links to older releases only work on
the published site and will be corrected after release.

Please take a look at the commons-logging-1.1.3 artifacts and vote!

[ ] +1 release it.
[ ] +0 go ahead; I don't care.
[ ] -0 there are a few minor glitches: ...
[ ] -1 no, do not release it because ...

Vote will remain open for at least 72 hours.

Thanks in advance,

Thomas

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

Re: [pool] Maven failure

2013-05-22 Thread Oliver Heger


Am 22.05.2013 18:22, schrieb Gary Gregory:

When I build [pool] trunk with 'mvn clean site', I get:

[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 3:48.965s
[INFO] Finished at: Wed May 22 12:18:42 EDT 2013
[INFO] Final Memory: 59M/559M
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on
project commons-dbcp2: Error during page generation: Error rendering Maven
report: Failed during checkstyle configuration: cannot
  initialize module PackageHtml - Unable to instantiate PackageHtml: Unable
to instantiate PackageHtmlCheck -> [Help 1]


Errors like that can be caused by updating the version of the maven 
checkstyle plug-in. Newer versions also use newer checkstyle versions, 
and obviously there are sometimes incompatible changes in the format of 
the checkstyle configuration. I had similar problems recently at work.


Typically, it is not too difficult to find out what has changed and how 
to correct the problem (e.g. a tag in the configuration file has to be 
moved to another section, or attribute names have changed). However, it 
is still some effort to investigate.


Oliver


[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

I use:

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
08:51:28-0500)
Maven home: C:\Java\apache-maven-3.0.5\bin\..
Java version: 1.7.0_21, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_21\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

Does anyone else get this?

Gary




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

[OT] git and svn properties

2013-05-25 Thread Oliver Heger


Hi all,

recently I switched from svn to git and now use git svn to do my commits.

One problem I have with this setup is that git svn does not honor the 
autoprops configured for svn. Therefore, all newly added files are 
missing these properties.


I think I am not the only git user here. So I would like to ask how 
others address this problem.


Thanks in advance!
Oliver

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

Re: [OT] git and svn properties

2013-05-26 Thread Oliver Heger


Hi Luc,

Am 25.05.2013 21:53, schrieb Luc Maisonobe:

Le 25/05/2013 21:16, Oliver Heger a écrit :

Hi all,


Hi Oliver,



recently I switched from svn to git and now use git svn to do my commits.

One problem I have with this setup is that git svn does not honor the
autoprops configured for svn. Therefore, all newly added files are
missing these properties.

I think I am not the only git user here. So I would like to ask how
others address this problem.


This is the setting I have been used for months (probably more than one
year).

This seems strange to me, I thought git svn honoured the autoprops.
Looking back at a commit where I created lots of newx files (like
<http://markmail.org/message/4yb4yzp2ixqvhl2e>), the properties where
set properly. So I think it works for me. In my case, I work on Linux
and the subversion properties are set in a file $HOME/.subversion/config.

There is also one specific property that may need to be set specifically
for git, it is the line-endings encoding. On a Linux machine, I globally
set "core.autocrlf" ot "input" (the setting must be different for Windows).

thanks for your answer. Hm, it may be an OS-specific issue then (I am on 
Windows).


I found contradictory information on the net. While some say svn 
autoprops would work, there is the following statement in [1] (which 
should be the reference) in the "Bugs" section:


"We ignore all SVN properties except svn:executable."

Will have to do some more research, but currently I even don't know 
whether this is supposed to work :-( If somebody has a working 
configuration for Windows, please let me know!


Thanks
Oliver

[1] https://www.kernel.org/pub/software/scm/git/docs/git-svn.html


Luc




Thanks in advance!
Oliver

-
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: [OT] git and svn properties

2013-05-26 Thread Oliver Heger


Am 26.05.2013 21:39, schrieb Luc Maisonobe:

Le 26/05/2013 19:53, Gary Gregory a écrit :

Or... We could switch from svn to git.


+1 from me.

I have been using git for quite some time now and am particularly happy
with it (well I was also happy when I switched from SCCS to RCS to CVS
to SVN, and will probably also like what the next generation will bring
after Git).

One drawback, though, is that it needs some time to get used to it. We
should really have a large number of committers in favor of such a
change to do it. Just in order to have a rough idea, how many of us
already use Git, how many don't use it but would like to give it a try,
and how many don't want it?


I'm not sure if we could switch only some components first and the other
ones later on. As we already have a specific layout with two layers
(proper/sandbox/dormant) and then all the components, it may need some
tricks and help from infra.


This sounds reasonable. If we want to do such a move, we should do it 
carefully.


Anyway, you can count me to the group in favor of git. I don't want to 
miss it any more.


Oliver



Luc


I know, I know, I don't want
to start another 1000 message long thread. ;)

Gary

On May 26, 2013, at 13:06, Oliver Heger  wrote:


Hi Luc,

Am 25.05.2013 21:53, schrieb Luc Maisonobe:

Le 25/05/2013 21:16, Oliver Heger a écrit :

Hi all,


Hi Oliver,



recently I switched from svn to git and now use git svn to do my commits.

One problem I have with this setup is that git svn does not honor the
autoprops configured for svn. Therefore, all newly added files are
missing these properties.

I think I am not the only git user here. So I would like to ask how
others address this problem.


This is the setting I have been used for months (probably more than one
year).

This seems strange to me, I thought git svn honoured the autoprops.
Looking back at a commit where I created lots of newx files (like
<http://markmail.org/message/4yb4yzp2ixqvhl2e>), the properties where
set properly. So I think it works for me. In my case, I work on Linux
and the subversion properties are set in a file $HOME/.subversion/config.

There is also one specific property that may need to be set specifically
for git, it is the line-endings encoding. On a Linux machine, I globally
set "core.autocrlf" ot "input" (the setting must be different for Windows).

thanks for your answer. Hm, it may be an OS-specific issue then (I am on
Windows).

I found contradictory information on the net. While some say svn
autoprops would work, there is the following statement in [1] (which
should be the reference) in the "Bugs" section:

"We ignore all SVN properties except svn:executable."

Will have to do some more research, but currently I even don't know
whether this is supposed to work :-( If somebody has a working
configuration for Windows, please let me know!

Thanks
Oliver

[1] https://www.kernel.org/pub/software/scm/git/docs/git-svn.html


Luc




Thanks in advance!
Oliver

-
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




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

Re: [VOTE] Release NET 3.3 based on RC1

2013-06-08 Thread Oliver Heger

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


+1

One remark/question: I noticed that a jar for the sources, but none for 
the Javadocs is contained in the distribution. I don't have a problem 
with this, but did we agree on this? AFAICT, the recent releases for 
other Commons components shipped both jars.


Oliver

Am 08.06.2013 02:10, schrieb sebb:

This is a vote to release Apache Commons NET 3.3 based on RC1.

This is mainly a bug-fix release, but includes a few minor improvements.
NET 3.3 requires a minimum of Java 1.5

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

tag:
https://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_3_RC1/ (r1490853)

site:
http://people.apache.org/~sebb/commons-net-3.3-RC1/
All the links should work apart from the Download link

Source and binary archives (tar.gz and .zip) and Maven jars:
https://repository.apache.org/content/repositories/orgapachecommons-077/

[The tar.gz and .zip files will be moved to dist/commons/net before
promoting the Maven jars to release status]

Vote will remain open for at least 72 hours.

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




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

Re: [ALL] Strategy for developer tools (was: [VOTE] Commons Staging Plugin - move to proper from sandbox)

2013-06-22 Thread Oliver Heger


Am 22.06.2013 19:10, schrieb Gary Gregory:

On Jun 22, 2013, at 12:41, Phil Steitz  wrote:


On 6/22/13 7:26 AM, Mark Thomas wrote:

On 22/06/2013 14:45, Gary Gregory wrote:

I'm for whatever does the RM process easier and less error prone. If
that means maven plugins, so be it.

This is written as someone who has never released a commons component
and is very grateful for the folks that have done the release work for
the components he has been involved in.

I see various messages indicating how hard / complex / tricky / easy to
get wrong doing a release is. The frequency of the messages does not
appear to have changed significantly over time and they have been sent
but both newcomers to the project and folks that were here long before I
was.

I can't help but think that we must be doing something wrong. The Tomcat
release process is a breeze. It takes me about 2 minutes actual work. It
takes longer to upload the release artifacts for voting. And I spend
even longer making sure I am happy with what I am about to tag.

The obvious difference is that Tomcat is primarily an Ant based release
process with a little bit of Maven to talk to Nexus whereas the Commons
releases are primarily (wholly?) Maven based. However, I can't believe
that this is a tools issue. If everyone found Maven this hard to release
software with, no-one would be using it and it is clearly popular. That
begs the question: what are we doing wrong? Why do releases appear to be
much more difficult than they should be?

I don't have answers neither do I have the Maven knowledge I suspect is
necessary to figure the answers out. I encourage those that do have the
Maven skills to put on their thinking caps.


+1

I think that is what sebb and others have been doing working on
build plugins.  Lets agree on a simple way to make these plugins
available, get them really working, document their use and then
enjoy the stability :)

So in the spirit of removing barriers, I would like to propose the
following:

0) We designate a new class of commons components, called "commons
RM" or "commons-plugins."  These things do not have web sites and
are not otherwise advertised or promoted for use outside of
Commons.  Their sole purpose is to help Commons release managers
prepare and manipulate release candidates.  Their use should *not*
be required to execute the basic maven goals involved with building
the software - i.e., "mvn jar" and "mvn install" should work without
them.  In other words, users should be able to build from source
tags without them.

1) [RM] components can be released at any time via lazy consensus
VOTE, as we do now for commons parent.

2) RMs agree to collectively maintain these components and update
/releases so that the directions there work with currently released
versions of the [RM] plugins.

To get to windows of stability for the components I have released, I
have always resorted to custom bash scripts, which have worked fine
for me, but I understand a) not all RMs run unix b) we should be
trying to limit the things requiring shell access and c)
uncoordinated per-component scripts tend to break.  The advantage of
sebb's approach is that (like what the Tomcat Ant scripts do) it
eliminates the need for command-line scripting to create and manage
RCs.  With all of the maven expertise we have here, we should be
able to get something working that meets the needs of at least most
active Commons components.  Lets not get tied up in release
mechanics for the tools to make releases easier :)


+1. We can propose to graduate the plugins to Maven later when we have
them good and working for our use cases.


+1 from me, too. This seems to be a good approach.

Coming back to sebb's original proposal to access the plug-ins from a 
local maven repository: Would it be possible to integrate them (and our 
whole release process) into a CI environment? For instance, there could 
be Jenkins jobs that build and deploy an RC so that it is ready for a 
vote. Then RMs don't have do any local setup.


Oliver



Gary


Phil


Mark

-
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 of Commons Collections 4.0-alpha1 based on RC1

2013-06-24 Thread Oliver Heger

Hi Thomas,

first of all: Many thanks for your energy you put into this component!
You really did a great job!

Unfortunately, I do not have the time to have a closer look at the API,
so I can only vote based on technical checks of the artifacts.

Build works fine with Java 1.5 and 1.7 on Windows 7, artifacts and site
look good.

One minor point: The README.txt in the source distribution refers to a
collections test framework jar. Is this still correct, AFAICT no such
artifact is produced.

The build JDK seems to be 1.7.0_21. Because of the security issue
related to Javadoc it would be advisable to generate the site with the
latest update.

No blockers, so +1

Oliver

Am 23.06.2013 22:04, schrieb Thomas Neidhart:

Hi,

I'd like to call a vote for releasing Commons Collections 4.0-alpha1
based on RC1.

The files:

The artifacts are deployed to Nexus:
https://repository.apache.org/content/repositories/orgapachecommons-060/org/apache/commons/commons-collections4/4.0-alpha1/

Distribution files:
https://dist.apache.org/repos/dist/dev/commons/collections/

The tag:
https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_0_ALPHA1_RC1/

The site:
http://people.apache.org/builds/commons/collections/4.0-alpha1/RC1/

Additional Notes:

o the download page and api links to older releases only work on
the published site and will be corrected after release.

Please take a look at the commons-collections-4.0-alpha1 artifacts and vote!

[ ] +1 release it.
[ ] +0 go ahead; I don't care.
[ ] -0 there are a few minor glitches: ...
[ ] -1 no, do not release it because ...

Vote will remain open for at least 72 hours.

Thanks in advance,

Thomas

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

Re: [VOTE] Release of Commons Collections 4.0-alpha1 based on RC2

2013-07-01 Thread Oliver Heger


+1

Oliver

Am 30.06.2013 23:57, schrieb Thomas Neidhart:

Hi,

I'd like to call a vote for releasing Commons Collections 4.0-alpha1
based on RC2.

The following changes have been applied since RC1:

  * upgrade to maven-javadoc-plugin 2.9.1 (due to CVE-2013-1571)
  * fixed COLLECTIONS-474, thanks to sebb
  * fixed download page (contained wrong component id)
  * added html version of release notes for site

The artifacts / site have been built with Oracle JDK 1.5 build 1.5.0_22-b03.

The files:

The artifacts are deployed to Nexus:
https://repository.apache.org/content/repositories/orgapachecommons-092/org/apache/commons/commons-collections4/4.0-alpha1/

Distribution files:
https://dist.apache.org/repos/dist/dev/commons/collections/

The tag:
https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_0_ALPHA1_RC2/

The site:
http://people.apache.org/builds/commons/collections/4.0-alpha1/RC2/

Additional Notes:

o the download page and api links to older releases only work on
   the published site and will be corrected after release.

Please take a look at the commons-collections-4.0-alpha1 artifacts and vote!


[ ] +1 release it.
[ ] +0 go ahead; I don't care.
[ ] -0 there are a few minor glitches: ...
[ ] -1 no, do not release it because ...


Vote will remain open for at least 72 hours.

Thanks in advance,

Thomas

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




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

Re: [ALL] Alpha releases - how to stop them becoming a dependency of a released product

2013-07-05 Thread Oliver Heger


Am 05.07.2013 21:27, schrieb Paul Benedict:

Don't try to solve how to stop an alpha release from becoming integrated.
If someone does that, there's inherit risk involved. I don't see how this
is any different, per se, a beta or RC release. If you build on unstable
code, the only support advice I'd will get is: upgrade to the latest GA. :-)

IMHO we should lean towards innovation here rather than trying to 
prevent possible problems with people doing stupid things. The term 
"alpha release" should be well understood, so it should be obvious that 
this release is not intended to be used in projects claiming to be ready 
for production.


Oliver



On Fri, Jul 5, 2013 at 2:13 PM, sebb  wrote:


The thread about Collections Alpha release to Maven Central got me
thinking.

So long as an Alpha release is only used for testing/local use, it
does not matter where it is published.

The problem comes if the Alpha release becomes a dependency of another
product which is then released.

So how do we stop that from happening?

Documentation helps, but some people ignore documentation.

Just wondering if it would be possible to incorporate some kind of
time-limit in the library, so that it stops working after a certain
date?

I've no idea if that is feasible - and it might cause too much of an
overhead - but perhaps worth investigating.

Obviously it would have to be well documented.

-
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: [csv] record.get APIs for primitive types

2013-08-02 Thread Oliver Heger

Am 02.08.2013 02:34, schrieb James Carman:
> Okay, totally forgot we had ConvertUtils in BeanUtils.  So, since we
> have the functionality, especially for Strings, and it's extensible,
> we could recommend that in the Javadocs perhaps.
> 
> That Converter API is screaming for some generics action!

Just for the record and because [configuration] has already been
mentioned in this thread:

One of the next points on my todo list to get [configuration] 2.0 out is
to rework the conversion framework. Currently, we have a big class doing
all kinds of conversions. I am going to change this to have an
extensible converter framework.

I would really love to make use of [beanutils], however, as soon as some
classes of another project become part of your public API, you are tight
to this project. For instance, [configuration] 1.x depends on [lang]
2.x. After the major release of [lang] 3.0, we got many requests to
update the dependency, but this was not possible in a minor release due
to binary incompatible changes - because of the changed package
structure in [lang] the API of [configuration] would also change.

Something similar can happen with [beanutils], too - work on version 2.0
has already started.

Oliver

> 
> On Thu, Aug 1, 2013 at 8:23 PM, Paul Benedict  wrote:
>> I can see that we should provide a decorator/delegate (CSVRecordWrapper?)
>> that has these additional methods and defers them to Beanutils. We should
>> use our other Commons project to accomplish the pluggable and configurable
>> conversion. Beanutils can be an optional Maven dependency. This doesn't
>> belong in Commons Langs, because that's where the functionality was before
>> migrating to its own BeanUtils project (circa 2001ish).
>> On Aug 1, 2013 7:06 PM, "James Carman"  wrote:
>>
>>> Perhaps it belongs in Commons Lang?
>>>
>>> Anything like this that you try to put together is going to blow up
>>> really quickly, by the way (registering new converter types, etc.).  I
>>> don't see how having a few little helper methods in CSV is that big of
>>> an issue, personally.
>>>
>>> On Thu, Aug 1, 2013 at 7:59 PM, Paul Benedict
>>>  wrote:
 You might want to think of a conversion addon package using Common
 BeanUtils. That project is skilled at conversions from String and has
 pluggable capability to customize conversion types.
 On Aug 1, 2013 6:51 PM, "Paul Benedict"  wrote:

> None of these methods document exceptions if the conversion fails (eg,
>>> not
> an integer). Also, how strict is the conversion? Can "x" represent
>>> boolean
> false or is that an exception?
> On Aug 1, 2013 9:00 AM, "Gary Gregory"  wrote:
>
>> I would like to note this CSVRecord addition I am planning on:
>>
>> public Boolean getBoolean(String name) {
>> public boolean getBooleanPrimitive(String name)
>>
>> The method listings are at the end of this message.
>>
>> What I want to note here is that these are conversion methods and that
>>> the
>> record still stores the values internally as Strings. I do not want to
>> Javadoc the conversion in order to give us flexibility over
>>> representation
>> if we decide to change it in the future (caching or whatnot).
>>
>> I wanted to post here in CTR mode before I or others add APIs like
>> getLong() and getLongPrimitive(). Since this is a library, I do
>>> believe we
>> should end up providing such APIs at the record level for primitives.
>>
>> /**
>>  * Returns a value by name.
>>  *
>>  * @param name
>>  *the name of the column to be retrieved.
>>  * @return the column value, or {@code null} if the column name is
>>> not
>> found
>>  * @throws IllegalStateException
>>  * if no header mapping was provided
>>  * @throws IllegalArgumentException
>>  * if the record is inconsistent
>>  * @see #isConsistent()
>>  */
>> public Boolean getBoolean(String name) {
>> String s = this.get(name);
>> return s != null ? Boolean.valueOf(s) : null;
>> }
>>
>> /**
>>  * Returns a value by name.
>>  *
>>  * @param name
>>  *the name of the column to be retrieved.
>>  * @return the column value, or {@code false} if the column name is
>> not
>> found
>>  * @throws IllegalStateException
>>  * if no header mapping was provided
>>  * @throws IllegalArgumentException
>>  * if the record is inconsistent
>>  * @see #isConsistent()
>>  */
>> public boolean getBooleanPrimitive(String name) {
>> return Boolean.parseBoolean(this.get(name));
>> }
>>
>> Gary
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition<
>> h

[convert] Automatic conversion based on proxies

2013-08-13 Thread Oliver Heger

Hi all,

recently, there was a discussion about extending the [csv] interface to
provide data conversions to different types. If such a use case is to be
supported, what would be the best approach to integrate a library like
[convert]? Doing all required conversions manually would probably mean a
bunch of boilerplate code, wouldn't it?

I had an idea how to automate this use case. Given an interface with a
method
T getValue(...);
where T is some base type like String or Object. Now we want to provide
other methods like
int getValueAsInt(...);
long getValueAsLong(...);
...

If there is an extended interface with all getValueAsXXX() methods,
couldn't the conversion be done by a proxy? The invocation handler would
obtain the return type of the invoked method in order to determine the
target class of the conversion. It would then call the basic getValue()
method with the provided arguments, convert the result, and return it.

This is the general idea, in practice probably some filtering would be
needed to react only on certain method invocations.

Do you think this use case is generic enough to support it in [convert]
(e.g. by providing an abstract base class of an invocation handler and
some convenience methods for creating proxy objects)?

Oliver

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

Re: [convert] Automatic conversion based on proxies

2013-08-14 Thread Oliver Heger

Am 14.08.2013 16:54, schrieb Gary Gregory:
> On Tue, Aug 13, 2013 at 4:01 PM, Oliver Heger
> wrote:
> 
>> Hi all,
>>
>> recently, there was a discussion about extending the [csv] interface to
>> provide data conversions to different types. If such a use case is to be
>> supported, what would be the best approach to integrate a library like
>> [convert]?
> 
> 
> Well, the first step would be to release [Convert] 1.0 ;)
> 
> It seems there would first need to be agreement that conversion belongs in
> [csv] in the first place, which is not the case for [CSV] 1.0.
> 
> Personally, I'd like to focus on getting [CSV] 1.0 out the door and then
> adding features.
> 
> It is good to talk about conversion now of course because it may affect the
> [CSV] APIs we provide. We do want to be backward compatible.

Well, no objections. I only took [csv] as an example. The proposal was
related to [convert].

Oliver

> 
> 
> Gary
> 
> 
>> Doing all required conversions manually would probably mean a
>> bunch of boilerplate code, wouldn't it?
>>
>> I had an idea how to automate this use case. Given an interface with a
>> method
>> T getValue(...);
>> where T is some base type like String or Object. Now we want to provide
>> other methods like
>> int getValueAsInt(...);
>> long getValueAsLong(...);
>> ...
>>
>> If there is an extended interface with all getValueAsXXX() methods,
>> couldn't the conversion be done by a proxy? The invocation handler would
>> obtain the return type of the invoked method in order to determine the
>> target class of the conversion. It would then call the basic getValue()
>> method with the provided arguments, convert the result, and return it.
>>
>> This is the general idea, in practice probably some filtering would be
>> needed to react only on certain method invocations.
>>
>> Do you think this use case is generic enough to support it in [convert]
>> (e.g. by providing an abstract base class of an invocation handler and
>> some convenience methods for creating proxy objects)?
>>
>> Oliver
>>
>> -
>> 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: [convert] Automatic conversion based on proxies

2013-08-14 Thread Oliver Heger

Am 14.08.2013 17:39, schrieb Adrian Crum:
> I don't think CSV needs anything special to accommodate type conversion.
> 
> The pattern I tried to introduce in the Commons Convert "Getting
> Started" section is one that works in any part of an application where
> conversion might be needed. So, instead of hard-coding conversions, the
> developer creates a facade that accommodates conversion anywhere in the
> program (not just in CSV).
> 
> Instead of
> 
> int columnInt = record.getValueAsInt(1);
> 
> the developer would use
> 
> Integer columnInt = Util.convertTo(record.getValue(1), Integer.class);
> 
> By keeping type conversion separated, you can convert anything you
> encounter during development. Plus, this approach relieves CSV from
> being concerned with conversions - that is the developer's responsibility.
> 
> If a developer used Commons Convert, then they could keep conversion
> details out of the code entirely and design external declarative
> conversions:
> 
> 
>   
> 
> 
> 
>   
> 

I see. It's just in times of CDI developers expect that everything
happens automagically.

Oliver

> 
> -Adrian
> 
> 
> On 8/14/2013 7:54 AM, Gary Gregory wrote:
>> On Tue, Aug 13, 2013 at 4:01 PM, Oliver Heger
>> wrote:
>>
>>> Hi all,
>>>
>>> recently, there was a discussion about extending the [csv] interface to
>>> provide data conversions to different types. If such a use case is to be
>>> supported, what would be the best approach to integrate a library like
>>> [convert]?
>>
>> Well, the first step would be to release [Convert] 1.0 ;)
>>
>> It seems there would first need to be agreement that conversion
>> belongs in
>> [csv] in the first place, which is not the case for [CSV] 1.0.
>>
>> Personally, I'd like to focus on getting [CSV] 1.0 out the door and then
>> adding features.
>>
>> It is good to talk about conversion now of course because it may
>> affect the
>> [CSV] APIs we provide. We do want to be backward compatible.
>>
>>
>> Gary
>>
>>
>>> Doing all required conversions manually would probably mean a
>>> bunch of boilerplate code, wouldn't it?
>>>
>>> I had an idea how to automate this use case. Given an interface with a
>>> method
>>> T getValue(...);
>>> where T is some base type like String or Object. Now we want to provide
>>> other methods like
>>> int getValueAsInt(...);
>>> long getValueAsLong(...);
>>> ...
>>>
>>> If there is an extended interface with all getValueAsXXX() methods,
>>> couldn't the conversion be done by a proxy? The invocation handler would
>>> obtain the return type of the invoked method in order to determine the
>>> target class of the conversion. It would then call the basic getValue()
>>> method with the provided arguments, convert the result, and return it.
>>>
>>> This is the general idea, in practice probably some filtering would be
>>> needed to react only on certain method invocations.
>>>
>>> Do you think this use case is generic enough to support it in [convert]
>>> (e.g. by providing an abstract base class of an invocation handler and
>>> some convenience methods for creating proxy objects)?
>>>
>>> Oliver
>>>
>>> -
>>> 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: [convert] Automatic conversion based on proxies

2013-08-15 Thread Oliver Heger

Am 15.08.2013 15:33, schrieb James Carman:
> Perhaps you'd have a different method on the "registry" like this:
> 
> Converter createConverterPath(Class fromType, Class toType);
> 
> This way, you're specifically letting the registry know that you're
> okay with it filling in the blanks in between fromType and toType.
> 

The problem is that this stuff becomes pretty fast very complex.
Therefore, a strategy could be to handle this in separate layers.

- There would be a core layer providing basic converters from type A to
B. AIUI, this is what [convert] currently has.
- Then there is a layer of handling more complex conversions, e.g. the
transitive stuff and maybe also conversions with collections and arrays
involved. I guess, to implement this layer, you will need a registry and
some more meta data about the converters available.
- Another layer would be an integration layer into custom applications.
Here different patterns could be provided for triggering conversions
with more or less magic.

Oliver

> 
> On Thu, Aug 15, 2013 at 9:24 AM, Gary Gregory  wrote:
>> On Thu, Aug 15, 2013 at 9:09 AM, James Carman 
>> wrote:
>>
>>> You mean if it has a converter from A -> B and B -> C and you ask for
>>> a conversion from A -> C, it would figure it out?  That's and
>>> interesting idea.  I guess you'd need to make sure there is no loss of
>>> fidelity when doing the conversions.
>>>
>>
>> Yes, and be careful of the shortest path too:
>>
>> I can have:
>>
>> String -> Long
>> String -> Date
>> Date -> Long
>>
>> So when I ask for String -> Long, I do not want String -> Date -> Long!
>>
>> I have something like this at work I use for for (complex) objects.
>>
>> The other aspect is caching, let's say I have a Customer and I want to
>> convert it to XML and JSON, I want to cache the results of the conversion
>> and invalidate that cache if I change the customer. Is that out of scope? I
>> would be some kind of project object that holds on to a Customer, a JSON
>> string, and an XML document (both bytes and String).
>>
>> Gary
>>
>>
>>>
>>>
>>> On Thu, Aug 15, 2013 at 8:00 AM, Gary Gregory 
>>> wrote:
 Should the framework try to convert transitively?

 Gary

 On Aug 15, 2013, at 6:56, James Carman 
>>> wrote:

> I personally think we're over-thinking this thing.  Keep it simple,
>>> folks:
>
> public interface Converter
> {
>  T convert(F from);
> }
>
> You can auto-detect the F/T parameters when a Converter is registered.
>
> On Thu, Aug 15, 2013 at 4:42 AM, Jörg Schaible
>  wrote:
>> Hi,
>>
>> Emmanuel Bourg wrote:
>>
>>> Le 14/08/2013 17:39, Adrian Crum a écrit :
>>>
 Instead of

 int columnInt = record.getValueAsInt(1);

 the developer would use

 Integer columnInt = Util.convertTo(record.getValue(1),
>>> Integer.class);
>>>
>>> +1 for the static method, that would allow the use of a static import
>>> and a very concise syntax like:
>>>
>>> Integer columnInt = to(Integer.class, record.getValue(1));
>>>
>>>
>>> That being said, [convert] could offer several patterns to perform
>>> type
>>> conversion, and the use of proxies could be one of them.
>>
>> I never had a look at [convert], but this proposed syntax reminds me
>> strongly to an own little framework, where I have following methods in
>>> an
>> interface to convert strings into arbitrary objects:
>>
>> = %< ==
>>  T get(Class type, String key);
>>  T get(ValueConverter converter, String key);
>> = %< ==
>>
>> The value converter itself is very primitive:
>>
>> = %< ==
>> public interface ValueConverter
>> {
>>   T get(CharSequence value);
>> }
>> = %< ==
>>
>> The question is now, how to know about existing converters. I was
>>> inspired
>> by XStream and use a class ConverterLookup that has following method:
>>
>> = %< ==
>> public  ValueConverter lookup(final Class type)
>> {
>>   ValueConverter converter = converterCache.get(type);
>>   if (converter == null) {
>> for (final Iterator iter = converters.iterator();
>> converter == null && iter.hasNext();) {
>>   converter = iter.next().willConvert(type);
>> }
>>
>> synchronized (converterCache) {
>>   if (converter != null) {
>> converterCache.putIfAbsent(type, converter);
>>   }
>> }
>>   }
>>
>>   @SuppressWarnings("unchecked")
>>   final ValueConverter checkedConverter = (ValueConverter)
>>> converter;
>>   return checkedConverter;
>> }
>> = %< ==
>>
>> I.e. the ConverterLookup has a (priorized) set of ConverterFactory
>> implementa

[configuration] Inconsistencies in getList() method

2013-08-17 Thread Oliver Heger

I am currently trying to implement generic conversion methods (as they
already exist in DataConfiguration) in AbstractConfiguration to make
conversion available for all configurations.

This works in principal. However, when I try to implement the existing
getList() method by delegating to the new generic list conversion method
I discovered some inconsistent behavior of this method.

The documentation says that this method returns a list of strings. This
is not true; if the list contains itself complex objects, these objects
are returned in the result list. (In contrast, the generic list
conversion method recursively flattens the result list.) There are even
tests which test this behavior; it is used by the property list
configurations to represent nested arrays.

I am not sure how to proceed here. I see the following options:
1) Leave this method as it is, but document the behavior.
2) Change the method to be a thin wrapper over the generic list
conversion method which returns a List.

My preferred option would be 2), but then it might be necessary to
change the property list configurations to handle nested arrays in a
different way. (Maybe add a special getList() implementation here?)

Any opinions?
Oliver

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

Re: [configuration] Inconsistencies in getList() method

2013-08-19 Thread Oliver Heger

Am 17.08.2013 22:07, schrieb Oliver Heger:
> I am currently trying to implement generic conversion methods (as they
> already exist in DataConfiguration) in AbstractConfiguration to make
> conversion available for all configurations.
> 
> This works in principal. However, when I try to implement the existing
> getList() method by delegating to the new generic list conversion method
> I discovered some inconsistent behavior of this method.
> 
> The documentation says that this method returns a list of strings. This
> is not true; if the list contains itself complex objects, these objects
> are returned in the result list. (In contrast, the generic list
> conversion method recursively flattens the result list.) There are even
> tests which test this behavior; it is used by the property list
> configurations to represent nested arrays.
> 
> I am not sure how to proceed here. I see the following options:
> 1) Leave this method as it is, but document the behavior.
> 2) Change the method to be a thin wrapper over the generic list
> conversion method which returns a List.
> 
> My preferred option would be 2), but then it might be necessary to
> change the property list configurations to handle nested arrays in a
> different way. (Maybe add a special getList() implementation here?)
> 
> Any opinions?
> Oliver
> 

On a second thought, I guess I will not change the getList()
implementation, but only tweak its documentation. This has the least
effort. Currently, I don't have any itch to manipulate the property list
configurations.

Oliver

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

[ALL] Design question: static utility classes

2013-08-24 Thread Oliver Heger

Hi all,

regarding a principle design question I would like to get your opinion:

In [configuration] there are a few static utility classes. One of them
is BeanHelper which supports the creation of beans from configuration
data. The actual bean creation is done by a BeanFactory which can be
configured using the static (currently unsynchronized)
setDefaultBeanFactory() method.

Sebb stated correctly that this approach is thread-hostile [1]. An
alternative could be to make BeanHelper a non-static class which can be
instantiated and configured per instance. This would be more flexible
and would also simplify testing of client code (just pass in a mock
object). The drawback is that clients now always would have to create an
instance, so the API becomes slightly more verbose - in fact, most
clients will probably never have the requirement to change the default
bean factory.

So, the question is, what do you prefer? The static approach like
Object myBean = BeanHelper.createBean(...);

or using an instance as in
BeanHelper helper = new BeanHelper(myFactory);
// or use no-args ctor for default factory
Object myBean = helper.createBean(...);

TIA
Oliver

[1] https://issues.apache.org/jira/browse/CONFIGURATION-486

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

Re: [ALL] Design question: static utility classes

2013-08-26 Thread Oliver Heger

Am 25.08.2013 18:45, schrieb Adrian Crum:
> +1
> 
> -Adrian
> 
> On 8/25/2013 9:26 AM, James Carman wrote:
>> AtomicReference?

There are multiple aspects here. One is the safe publishing of a value
written into the member field. This can be achieved by atomic
references, synchronization, or a volatile field.

The other aspect is that such a field of a static utility class is
pretty global. You cannot have different values for different threads.

So the question is, is it good design to have static utility classes
with state?

For users, it may be more convenient to simply access functionality
through static methods, especially if the default values for static
member fields are reasonable for most use cases. However, such a design
makes it impossible to use the represented functionality with different
settings in parallel.

Also, I am not sure whether complex class loader scenarios (e.g. an
application server or an OSGi container) may cause problems with the
static approach.

Oliver

>>
>> On Sunday, August 25, 2013, Phil Steitz wrote:
>>
>>> On 8/24/13 11:33 AM, Oliver Heger wrote:
>>>> Hi all,
>>>>
>>>> regarding a principle design question I would like to get your opinion:
>>>>
>>>> In [configuration] there are a few static utility classes. One of them
>>>> is BeanHelper which supports the creation of beans from configuration
>>>> data. The actual bean creation is done by a BeanFactory which can be
>>>> configured using the static (currently unsynchronized)
>>>> setDefaultBeanFactory() method.
>>>>
>>>> Sebb stated correctly that this approach is thread-hostile [1]. An
>>>> alternative could be to make BeanHelper a non-static class which can be
>>>> instantiated and configured per instance. This would be more flexible
>>>> and would also simplify testing of client code (just pass in a mock
>>>> object). The drawback is that clients now always would have to
>>>> create an
>>>> instance, so the API becomes slightly more verbose - in fact, most
>>>> clients will probably never have the requirement to change the default
>>>> bean factory.
>>>>
>>>> So, the question is, what do you prefer? The static approach like
>>>> Object myBean = BeanHelper.createBean(...);
>>>>
>>>> or using an instance as in
>>>> BeanHelper helper = new BeanHelper(myFactory);
>>>> // or use no-args ctor for default factory
>>>> Object myBean = helper.createBean(...);
>>> Personally, I would like the static method better as a user.
>>> Synchronizing access to the static factory field would seem to fix
>>> the problem unless I am missing something.  Also, I would not expect
>>> lots of concurrent access to the getter/setter for this field in
>>> normal use cases , so the performance overhead of the sync would be
>>> immaterial.  Having the setter there may also be a little easier for
>>> dependency injection.
>>>
>>> Phil
>>>> TIA
>>>> Oliver
>>>>
>>>> [1] https://issues.apache.org/jira/browse/CONFIGURATION-486
>>>>
>>>> -
>>>> 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: [ALL] Design question: static utility classes

2013-08-26 Thread Oliver Heger

Am 26.08.2013 16:18, schrieb Phil Steitz:
> 
> 
> On Aug 26, 2013, at 7:38 PM, Oliver Heger  
> wrote:
> 
>> Am 25.08.2013 18:45, schrieb Adrian Crum:
>>> +1
>>>
>>> -Adrian
>>>
>>> On 8/25/2013 9:26 AM, James Carman wrote:
>>>> AtomicReference?
>>
>> There are multiple aspects here. One is the safe publishing of a value
>> written into the member field. This can be achieved by atomic
>> references, synchronization, or a volatile field.
>>
>> The other aspect is that such a field of a static utility class is
>> pretty global. You cannot have different values for different threads.
>>
>> So the question is, is it good design to have static utility classes
>> with state?
> 
> Excellent point.  The key question to ask is are there use cases where 
> different threads in the same JVM are really going to want different default 
> factories.  I wonder if any actual user of the current code has ever wanted 
> this.
> 
In this special case, I *assume* that there are hardly any concrete use
cases, but of course, we cannot be sure.

However, there may be other examples in [configuration]. Would it make
sense to be homogeneous here, i.e. use the same design principles for
all classes?

Oliver

> Phil 
>>
>> For users, it may be more convenient to simply access functionality
>> through static methods, especially if the default values for static
>> member fields are reasonable for most use cases. However, such a design
>> makes it impossible to use the represented functionality with different
>> settings in parallel.
>>
>> Also, I am not sure whether complex class loader scenarios (e.g. an
>> application server or an OSGi container) may cause problems with the
>> static approach.
>>
>> Oliver
>>
>>>>
>>>> On Sunday, August 25, 2013, Phil Steitz wrote:
>>>>
>>>>> On 8/24/13 11:33 AM, Oliver Heger wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> regarding a principle design question I would like to get your opinion:
>>>>>>
>>>>>> In [configuration] there are a few static utility classes. One of them
>>>>>> is BeanHelper which supports the creation of beans from configuration
>>>>>> data. The actual bean creation is done by a BeanFactory which can be
>>>>>> configured using the static (currently unsynchronized)
>>>>>> setDefaultBeanFactory() method.
>>>>>>
>>>>>> Sebb stated correctly that this approach is thread-hostile [1]. An
>>>>>> alternative could be to make BeanHelper a non-static class which can be
>>>>>> instantiated and configured per instance. This would be more flexible
>>>>>> and would also simplify testing of client code (just pass in a mock
>>>>>> object). The drawback is that clients now always would have to
>>>>>> create an
>>>>>> instance, so the API becomes slightly more verbose - in fact, most
>>>>>> clients will probably never have the requirement to change the default
>>>>>> bean factory.
>>>>>>
>>>>>> So, the question is, what do you prefer? The static approach like
>>>>>> Object myBean = BeanHelper.createBean(...);
>>>>>>
>>>>>> or using an instance as in
>>>>>> BeanHelper helper = new BeanHelper(myFactory);
>>>>>> // or use no-args ctor for default factory
>>>>>> Object myBean = helper.createBean(...);
>>>>> Personally, I would like the static method better as a user.
>>>>> Synchronizing access to the static factory field would seem to fix
>>>>> the problem unless I am missing something.  Also, I would not expect
>>>>> lots of concurrent access to the getter/setter for this field in
>>>>> normal use cases , so the performance overhead of the sync would be
>>>>> immaterial.  Having the setter there may also be a little easier for
>>>>> dependency injection.
>>>>>
>>>>> Phil
>>>>>> TIA
>>>>>> Oliver
>>>>>>
>>>>>> [1] https://issues.apache.org/jira/browse/CONFIGURATION-486
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail:
>>>>>> dev-unsubscr...@commons.apache.org
>>>>>> For additiona

Re: [ALL] Design question: static utility classes

2013-08-27 Thread Oliver Heger

Am 27.08.2013 07:06, schrieb Phil Steitz:
> On 8/26/13 11:28 AM, Oliver Heger wrote:
>> Am 26.08.2013 16:18, schrieb Phil Steitz:
>>>
>>> On Aug 26, 2013, at 7:38 PM, Oliver Heger  
>>> wrote:
>>>
>>>> Am 25.08.2013 18:45, schrieb Adrian Crum:
>>>>> +1
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 8/25/2013 9:26 AM, James Carman wrote:
>>>>>> AtomicReference?
>>>> There are multiple aspects here. One is the safe publishing of a value
>>>> written into the member field. This can be achieved by atomic
>>>> references, synchronization, or a volatile field.
>>>>
>>>> The other aspect is that such a field of a static utility class is
>>>> pretty global. You cannot have different values for different threads.
>>>>
>>>> So the question is, is it good design to have static utility classes
>>>> with state?
>>> Excellent point.  The key question to ask is are there use cases where 
>>> different threads in the same JVM are really going to want different 
>>> default factories.  I wonder if any actual user of the current code has 
>>> ever wanted this.
>>>
>> In this special case, I *assume* that there are hardly any concrete use
>> cases, but of course, we cannot be sure.
>>
>> However, there may be other examples in [configuration]. Would it make
>> sense to be homogeneous here, i.e. use the same design principles for
>> all classes?
> 
> Yes and the non-static approach is certainly more flexible, so on
> balance I think you and James are right.

Many thanks for the feedback! So I think I will go for the "bean-based
approach" then.

Oliver

> 
> Phil
>>
>> Oliver
>>
>>> Phil 
>>>> For users, it may be more convenient to simply access functionality
>>>> through static methods, especially if the default values for static
>>>> member fields are reasonable for most use cases. However, such a design
>>>> makes it impossible to use the represented functionality with different
>>>> settings in parallel.
>>>>
>>>> Also, I am not sure whether complex class loader scenarios (e.g. an
>>>> application server or an OSGi container) may cause problems with the
>>>> static approach.
>>>>
>>>> Oliver
>>>>
>>>>>> On Sunday, August 25, 2013, Phil Steitz wrote:
>>>>>>
>>>>>>> On 8/24/13 11:33 AM, Oliver Heger wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> regarding a principle design question I would like to get your opinion:
>>>>>>>>
>>>>>>>> In [configuration] there are a few static utility classes. One of them
>>>>>>>> is BeanHelper which supports the creation of beans from configuration
>>>>>>>> data. The actual bean creation is done by a BeanFactory which can be
>>>>>>>> configured using the static (currently unsynchronized)
>>>>>>>> setDefaultBeanFactory() method.
>>>>>>>>
>>>>>>>> Sebb stated correctly that this approach is thread-hostile [1]. An
>>>>>>>> alternative could be to make BeanHelper a non-static class which can be
>>>>>>>> instantiated and configured per instance. This would be more flexible
>>>>>>>> and would also simplify testing of client code (just pass in a mock
>>>>>>>> object). The drawback is that clients now always would have to
>>>>>>>> create an
>>>>>>>> instance, so the API becomes slightly more verbose - in fact, most
>>>>>>>> clients will probably never have the requirement to change the default
>>>>>>>> bean factory.
>>>>>>>>
>>>>>>>> So, the question is, what do you prefer? The static approach like
>>>>>>>> Object myBean = BeanHelper.createBean(...);
>>>>>>>>
>>>>>>>> or using an instance as in
>>>>>>>> BeanHelper helper = new BeanHelper(myFactory);
>>>>>>>> // or use no-args ctor for default factory
>>>>>>>> Object myBean = helper.createBean(...);
>>>>>>> Personally, I would like the static method better as a user.
>>>>>>> Synchronizing access to the static

Re: [DISCUSS] Math TLP...

2013-08-27 Thread Oliver Heger

Am 27.08.2013 15:57, schrieb Phil Steitz:
> On 8/27/13 6:31 AM, James Carman wrote:
>> It was mentioned the other day, so I thought I would propose a formal
>> discussion.  Is it time to let [math] "leave the nest"?  I would doubt
>> there are very many of us qualified to work on such a library here in
>> Commons.  I have a degree in Mathematics, but I haven't used the
>> advanced math in such a long time that I probably wouldn't even really
>> know where to start.  Would it be easier to build a larger community
>> around a new TLP?  Would it be more visible that way, as opposed to
>> being tucked away in our little neck of the woods?
> 
> Here is just one HO:
> 
> We get big benefit from contributions from non-mathematicians in
> [math].  In fact, I suspect that most of the core developers are not
> mathematicians by training.  Sure, we need mathematical knowledge to
> develop algorithms, but there is a boatload of stuff that we get
> valuable help from other commons community members on.
> 
> I am not sure TLP would make much of a difference in terms of
> "visibility" and I don't think we are not really hurting for that,
> IMO.  What we need is what other commons components need - committed
> committers.  We have found them here and I am sure we will continue
> to find more.
> 
> One final comment is that some of us also help on other components,
> so [math] is itself a source of volunteers for commons.
> 
> So my HO is both [math] and commons are better off staying
> together.  I understand fully; however, if those not interested in
> [math] feel differently and would rather see us move to TLP.

My HO is also that [math] should stay here in commons. There is indeed
synergy.

I use to skip the discussions requiring mathematical knowledge and
background, but the ones related to design and programming issues are
quite interesting.

Oliver

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

Re: [ALL] Design question: static utility classes

2013-08-29 Thread Oliver Heger

Am 29.08.2013 10:26, schrieb Benedikt Ritter:
> 2013/8/27 Oliver Heger 
> 
>> Am 27.08.2013 07:06, schrieb Phil Steitz:
>>> On 8/26/13 11:28 AM, Oliver Heger wrote:
>>>> Am 26.08.2013 16:18, schrieb Phil Steitz:
>>>>>
>>>>> On Aug 26, 2013, at 7:38 PM, Oliver Heger <
>> oliver.he...@oliver-heger.de> wrote:
>>>>>
>>>>>> Am 25.08.2013 18:45, schrieb Adrian Crum:
>>>>>>> +1
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 8/25/2013 9:26 AM, James Carman wrote:
>>>>>>>> AtomicReference?
>>>>>> There are multiple aspects here. One is the safe publishing of a value
>>>>>> written into the member field. This can be achieved by atomic
>>>>>> references, synchronization, or a volatile field.
>>>>>>
>>>>>> The other aspect is that such a field of a static utility class is
>>>>>> pretty global. You cannot have different values for different threads.
>>>>>>
>>>>>> So the question is, is it good design to have static utility classes
>>>>>> with state?
>>>>> Excellent point.  The key question to ask is are there use cases where
>> different threads in the same JVM are really going to want different
>> default factories.  I wonder if any actual user of the current code has
>> ever wanted this.
>>>>>
>>>> In this special case, I *assume* that there are hardly any concrete use
>>>> cases, but of course, we cannot be sure.
>>>>
>>>> However, there may be other examples in [configuration]. Would it make
>>>> sense to be homogeneous here, i.e. use the same design principles for
>>>> all classes?
>>>
>>> Yes and the non-static approach is certainly more flexible, so on
>>> balance I think you and James are right.
>>
>> Many thanks for the feedback! So I think I will go for the "bean-based
>> approach" then.
>>
> 
> One possibility to have the best of both worlds is to create a class with
> all static methods that delegates to an instance that is hold in a static
> field. This would be for all those that want the default behavior. Those
> who need customized behavior could instanciate the delegate directly an
> configure it the way they like:
> 
> public final class BeanHelperUtils {
> 
>private static final BeanHelper DELEGATE = new BeanHelper(new
> DefaultBeanFactory());
> 
>public static Bean someMethod() {
>   return DELEGATE.someMethod();
>}
> 
> }
> 
> public class BeanHelper {
> 
>private final BeanFactory factory;
> 
>public BeanHelper(BeanFactory factory) {
>   this.factory = factory;
>}
> 
>public Bean someMethod() {
>   factory.createBean();
>}
> }
> 
> client code can either call BeanHelperUtils.someMethod()
> or create a BeanHelper with the appropriate BeanFactory instance...

I was thinking about such a hybrid approach, too. But then, giving users
too many options and alternatives could be again confusing.

Oliver

> 
> just my 2 cents
> Benedikt
> 
> 
>>
>> Oliver
>>
>>>
>>> Phil
>>>>
>>>> Oliver
>>>>
>>>>> Phil
>>>>>> For users, it may be more convenient to simply access functionality
>>>>>> through static methods, especially if the default values for static
>>>>>> member fields are reasonable for most use cases. However, such a
>> design
>>>>>> makes it impossible to use the represented functionality with
>> different
>>>>>> settings in parallel.
>>>>>>
>>>>>> Also, I am not sure whether complex class loader scenarios (e.g. an
>>>>>> application server or an OSGi container) may cause problems with the
>>>>>> static approach.
>>>>>>
>>>>>> Oliver
>>>>>>
>>>>>>>> On Sunday, August 25, 2013, Phil Steitz wrote:
>>>>>>>>
>>>>>>>>> On 8/24/13 11:33 AM, Oliver Heger wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> regarding a principle design question I would like to get your
>> opinion:
>>>>>>>>>>
>>>>>>>>>> In [configuration] there are a few static utility class

Re: commons-lang pull request: Adding .gitignore to commons-lang

2013-08-29 Thread Oliver Heger

Am 29.08.2013 12:31, schrieb sebb:
> On 29 August 2013 09:01, Benedikt Ritter  wrote:
>> Hi,
>>
>> two questions about this:
>>
>> 1. What is the process for applying github pull requests? I guess one has
>> to generate a patch file and apply it directly to the SVN Repo?
> 
> It's difficult to track patches in mail messages, so I suggest
> creating a JIRA issue with the details.
> 
>> 2. Do we add .gitignore files to our repos even though our primary SCM is
>> SVN? It makes sense since everything is mirrored to git.
> 
> I think that's OK; they don't do any harm.
The problem I see with .gitignore files is that they are likely to run
out of sync with the svn:ignore attributes.

Not sure whether this helps in this special case, but there is an
alternative to a .gitignore file: the file .git/info/exclude in the
local git repository. Here a developer can add patterns for files to be
ignored as well. If a svn repository was cloned with git, the file can
be automatically populated from svn:ignore attributes using the command
git svn show-ignore > .git/info/exclude

Oliver

> 
> [Note that the Eclipse .project and .classpath files should NOT be
> committed to SVN; unfortunately they vary with the host
> configuration.]
> 
>> Benedikt
>>
>>
>> 2013/8/24 mureinik 
>>
>>> GitHub user mureinik opened a pull request:
>>>
>>> https://github.com/apache/commons-lang/pull/8
>>>
>>> Adding .gitignore to commons-lang
>>>
>>> Added .gitignore to the project in order to make working with git
>>> easier, and avoid accidentally commiting files that should not be commited.
>>>
>>> These patches currently introduce two sets of ignored files:
>>> First patch: Maven's build products (the target folder)
>>> Second patch: IntelliJ IDEA's files
>>>
>>> I'll happily add other files (e.g., Eclipse's file, other IDEs) if you
>>> wish.
>>>
>>> You can merge this pull request into a Git repository by running:
>>>
>>> $ git pull https://github.com/mureinik/commons-lang gitignore
>>>
>>> Alternatively you can review and apply these changes as the patch at:
>>>
>>> https://github.com/apache/commons-lang/pull/8.patch
>>>
>>> 
>>>
>>> 
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
> 
> -
> 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: [continuum] BUILD FAILURE: Apache Commons - Commons Configuration - Group (shared) Maven 3 Build Definition (Java 1.6)

2013-09-11 Thread Oliver Heger

Hm, seems that continuum operates on a dirty working copy. The class it
reports a compilation error no longer exists in this package (it has
been moved). Does anybody know how to fix this?

[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/home/continuum/continuum-base/data/working-directory/72/src/main/java/org/apache/commons/configuration/FileSystem.java:[114,29]
cannot find symbol
symbol  : class DefaultFileSystem
location: class org.apache.commons.configuration.FileSystem
[ERROR]
/home/continuum/continuum-base/data/working-directory/72/src/main/java/org/apache/commons/configuration/FileSystem.java:[137,25]
cannot find symbol
symbol  : class DefaultFileSystem
location: class org.apache.commons.configuration.FileSystem
[INFO] 2 errors
[INFO] -
[INFO]

[INFO] BUILD FAILURE

Oliver

Am 11.09.2013 22:20, schrieb Continuum@vmbuild:
> Online report : 
> http://vmbuild.apache.org/continuum/buildResult.action?buildId=27463&projectId=72
> 
> Build statistics:
>   State: Failed
>   Previous State: Failed
>   Started at: Wed 11 Sep 2013 20:20:07 +
>   Finished at: Wed 11 Sep 2013 20:20:30 +
>   Total time: 22s
>   Build Trigger: Schedule
>   Build Number: 299
>   Exit code: 1
>   Building machine hostname: vmbuild
>   Operating system : Linux(unknown)
>   Java Home version : 
>   java version "1.6.0_30"
>   Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
>   Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
> 
>   Builder version :
>   Apache Maven 3.0.2 (r1056850; 2011-01-09 00:58:10+)
>   Java version: 1.6.0_30, vendor: Sun Microsystems Inc.
>   Java home: /usr/lib/jvm/jdk1.6.0_30/jre
>   Default locale: en_US, platform encoding: ANSI_X3.4-1968
>   OS name: "linux", version: "2.6.32-41-server", arch: "amd64", 
> family: "unix"
> 
> 
> SCM Changes:
> 
> Changed: oheger @ Wed 11 Sep 2013 19:37:10 +
> Comment: CatalogResolver no longer uses FileSystem.getInputStream(String, 
> String).
> 
> Instead, in a first step a URL is retrieved via FileLocatorUtils.locate(). 
> Then
> from the URL an input stream is opened. After this change, FileSystem's
> getInputStream(String, String) method is no longer used.
> Files changed:
>   
> /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/resolver/CatalogResolver.java
>  ( 1522004 )
> 
> Changed: oheger @ Wed 11 Sep 2013 19:37:53 +
> Comment: Removed getInputStream(String, String) method from FileSystem.
> 
> This method is no longer called by any component.
> Files changed:
>   
> /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/io/DefaultFileSystem.java
>  ( 1522005 )
>   
> /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/io/FileSystem.java
>  ( 1522005 )
>   
> /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/io/VFSFileSystem.java
>  ( 1522005 )
> 
> 
> Dependencies Changes:
> 
> No dependencies changed
> 
> 
> 
> Build Definition:
> 
> POM filename: pom.xml
> Goals: clean deploy   
> Arguments: --batch-mode -Pjava-1.6 -Dgpg.skip -Prelease
> Build Fresh: false
> Always Build: false
> Default Build Definition: true
> Schedule: COMMONS_SCHEDULE
> Profile Name: Maven 3.0.2
> Description: Group (shared) Maven 3 Build Definition (Java 1.6)
> 
> 
> 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
> 


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

Re: [continuum] BUILD FAILURE: Apache Commons - Commons Configuration - Group (shared) Maven 3 Build Definition (Java 1.6)

2013-09-12 Thread Oliver Heger

Many thanks for having looked into this!

Oliver

Am 11.09.2013 22:51, schrieb sebb:
> The group build definition is set to use SCM update rather than a
> clean checkout.
> However surely svn update should remove deleted files?
> Dunno what the bug is here.
> 
> Changing to clean checkout for all Commons components seems unnecessary.
> But a temporary change + forced build + revert the change should fix it.
> I'll try that shortly.
> 
> On 11 September 2013 21:26, Oliver Heger  wrote:
>> Hm, seems that continuum operates on a dirty working copy. The class it
>> reports a compilation error no longer exists in this package (it has
>> been moved). Does anybody know how to fix this?
>>
>> [INFO] -
>> [ERROR] COMPILATION ERROR :
>> [INFO] -
>> [ERROR]
>> /home/continuum/continuum-base/data/working-directory/72/src/main/java/org/apache/commons/configuration/FileSystem.java:[114,29]
>> cannot find symbol
>> symbol  : class DefaultFileSystem
>> location: class org.apache.commons.configuration.FileSystem
>> [ERROR]
>> /home/continuum/continuum-base/data/working-directory/72/src/main/java/org/apache/commons/configuration/FileSystem.java:[137,25]
>> cannot find symbol
>> symbol  : class DefaultFileSystem
>> location: class org.apache.commons.configuration.FileSystem
>> [INFO] 2 errors
>> [INFO] -
>> [INFO]
>> 
>> [INFO] BUILD FAILURE
>>
>> Oliver
>>
>> Am 11.09.2013 22:20, schrieb Continuum@vmbuild:
>>> Online report : 
>>> http://vmbuild.apache.org/continuum/buildResult.action?buildId=27463&projectId=72
>>>
>>> Build statistics:
>>>   State: Failed
>>>   Previous State: Failed
>>>   Started at: Wed 11 Sep 2013 20:20:07 +
>>>   Finished at: Wed 11 Sep 2013 20:20:30 +
>>>   Total time: 22s
>>>   Build Trigger: Schedule
>>>   Build Number: 299
>>>   Exit code: 1
>>>   Building machine hostname: vmbuild
>>>   Operating system : Linux(unknown)
>>>   Java Home version :
>>>   java version "1.6.0_30"
>>>   Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
>>>   Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
>>>
>>>   Builder version :
>>>   Apache Maven 3.0.2 (r1056850; 2011-01-09 00:58:10+)
>>>   Java version: 1.6.0_30, vendor: Sun Microsystems Inc.
>>>   Java home: /usr/lib/jvm/jdk1.6.0_30/jre
>>>   Default locale: en_US, platform encoding: ANSI_X3.4-1968
>>>   OS name: "linux", version: "2.6.32-41-server", arch: "amd64", 
>>> family: "unix"
>>>
>>> 
>>> SCM Changes:
>>> 
>>> Changed: oheger @ Wed 11 Sep 2013 19:37:10 +
>>> Comment: CatalogResolver no longer uses FileSystem.getInputStream(String, 
>>> String).
>>>
>>> Instead, in a first step a URL is retrieved via FileLocatorUtils.locate(). 
>>> Then
>>> from the URL an input stream is opened. After this change, FileSystem's
>>> getInputStream(String, String) method is no longer used.
>>> Files changed:
>>>   
>>> /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/resolver/CatalogResolver.java
>>>  ( 1522004 )
>>>
>>> Changed: oheger @ Wed 11 Sep 2013 19:37:53 +
>>> Comment: Removed getInputStream(String, String) method from FileSystem.
>>>
>>> This method is no longer called by any component.
>>> Files changed:
>>>   
>>> /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/io/DefaultFileSystem.java
>>>  ( 1522005 )
>>>   
>>> /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/io/FileSystem.java
>>>  ( 1522005 )
>>>   
>>> /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/io/VFSFileSystem.java
>>>  ( 1522005 )
>>>
>>> 
>>> Dependencies Changes:
>>> ***

Re: svn commit: r1524542 - /commons/proper/lang/trunk/src/changes/changes.xml

2013-09-18 Thread Oliver Heger

Am 18.09.2013 22:02, schrieb Benedikt Ritter:
> Hi Oliver,
> 
> don't you have to add Woonsan to the contributors section of pom.xml? Or is
> that optional?
> 
> Benedikt
> 
Well, I don't think there is a strict policy in place. Usually, I ask
the contributor if he wants to be added to the list after a repeated
contribution. This also depends on the size and quality of the patches.

Oliver

> 
> 2013/9/18 
> 
>> Author: oheger
>> Date: Wed Sep 18 19:37:36 2013
>> New Revision: 1524542
>>
>> URL: http://svn.apache.org/r1524542
>> Log:
>> [LANG-893] Updated changes.xml.
>>
>> Modified:
>> commons/proper/lang/trunk/src/changes/changes.xml
>>
>> Modified: commons/proper/lang/trunk/src/changes/changes.xml
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/changes/changes.xml?rev=1524542&r1=1524541&r2=1524542&view=diff
>>
>> ==
>> --- commons/proper/lang/trunk/src/changes/changes.xml (original)
>> +++ commons/proper/lang/trunk/src/changes/changes.xml Wed Sep 18 19:37:36
>> 2013
>> @@ -22,6 +22,7 @@
>>
>>
>>
>> +StrSubstitutor now supports default values for variables
>>  Adding .gitignore to commons-lang
>>  Add ObjectUtils.toIdentityString
>> methods that support StringBuilder, StrBuilder, and Appendable
>>  BooleanUtils.toBoolean(String str) javadoc is not updated
>>
>>
>>
> 
> 


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

Re: [VOTE] Promote [weaver] component out of sandbox

2013-09-21 Thread Oliver Heger

+1

Oliver

Am 20.09.2013 19:49, schrieb Matt Benson:
> Hi Commons developers,
>   I hereby propose a vote to promote the [weaver] sandbox component to
> Commons proper.  My intent is that the promotion would be followed by a
> release of Apache Commons Weaver v1.0.
> 
> This vote will be open for at least 72 hours.
> 
> [ ] +1, Promote it!
> [ ] +0, Whatever
> [ ] -0, Meh
> [ ] -1, Keep it in the sandbox for now, and here's why:
> 
> Thanks,
> Matt
> 


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

Re: [DISCUSS] Mission Statement for Commons...

2013-10-06 Thread Oliver Heger

Hi Christian,

Am 06.10.2013 21:44, schrieb Christian Grobmeier:
> James,
> 
> thank you.
> 
> I believe Commons is in a bad shape.
> 
> Look at Commons Collections. Before 4 years somebody
> said Guava is more modern, he his answer seems to be widely accepted.
> http://stackoverflow.com/a/167/690771
> This guy said we have no generics. What did we do in the past 4 years?
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22
> 
> 
> Nothing. At least nothing visible. Its fine we have a beta. I wonder why
> we haven't managed
> to officially release this? The last release is from 2008.
> 
> I did consider to put my JSON component to Commons. But I didn't.
> Reason: I really need the component
> and I calculated how long it would take to release it here. I thought,
> it's not helping me
> to develop it here. I simply don't have the time.
> 
> I thought a long while about it.
> 
> We had discussions like: do we really need Generics? It works without!
> Do we really drop an outdated JDK? We might have users
> who run JDK 1.3! And so on. Finally this led us to the situation where
> almost all of our users seem to have JDK 1.3 and
> are not interested in generics - in 2013. The users who want modern
> features go to Guava. We maintain legacy code. And seriously, a lot of
> code works without generics. This is no reason to not include them.
> 
> We discuss magic strings in the sandbox. Why? We don't need to discuss
> that. Before we release we can simply check Sonar. Safe the time to
> discuss. Fix it or leave it to Sonar to report it.
> 
> We seem to think perfect documentation is more valuable then quick
> releases. Is it?
> 
> We seem to be proud of our build. I am not. It's complex. It's no fun.
> Releases should be do-able in a short time, maybe
> even automated.
> 
> It is so sad that lot of good features like Collections with Generics
> were blocked such a long time or drowning in discussions.
> 
> I agree we should support old users. But if we don't have the manpower,
> we can't support them. They need to accept we are moving on. We are
> blocked with our backwards compatible ideas and innovation is far away.
> 
> When I spoke to young developers about Commons they asked me if it still
> exists. Nobody of them is interested in our community.
> 
> For the mission statement I would wish to see things like that:
> 
> Commons Components…
> 
> …are released quickly and often
> …do use modern JDKs and support old JDKs only as long as they are
> supported by Oracle
> …we make use of modern Java features when they are available
> …can be easily released
> …can be released without having 100% perfect documentation or perfect
> implementations
> …are build by Community who wants to learn, experiment and create new
> features more than by Community which wants to be backwards compatible
> for a long time
> …are allowed to release major versions with api breaks as they want
> 
> Cheers
> Christian
> 
> 
I agree with many of your points. Another example is [csv] which is
about to be released for ages. Here, I think, the main impediment is
that we try to come up with a *perfect* API because due to our rules of
backwards compatibility it is so difficult to correct any mistakes later.

I still think that backwards compatibility is very important, but we
really should define a process which allows us to experiment with new APIs.

As a suggestion to improve this situation, could we agree on an alpha
release process allowing us to push releases with the aim of getting
community feedback? Where we explicitly state that incompatible changes
are possible (and likely)?

We did something similar with [collections] 4, but there were many
limitations (the release was not allowed to be uploaded to Maven central
for instance). If we did such experimental releases more often, there
would hopefully not be the fear of defining a broken API, and we would
see more releases.

Oliver

> 
> On 6 Oct 2013, at 20:30, James Carman wrote:
> 
>> All,
>>
>> The Apache Commons project seems to be languishing as of late and we
>> need some rejuvenation.  Perhaps we should try to define our mission
>> as a project.  What are our goals?  What do we want to accomplish?
>> Who are our users/customers?  What non-functional qualities do we want
>> our software to exhibit?  How do we want to conduct ourselves?  How
>> often do we want to do releases?  What else?
>>
>> Sincerely,
>>
>> James
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
> ---
> http://www.grobmeier.de
> @grobmeier
> GPG: 0xA5CC90DB
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

Re: [DISCUSS] Putting several unmaintained components to dormant

2013-10-10 Thread Oliver Heger

Am 09.10.2013 21:17, schrieb Benedikt Ritter:
> Hi,
> 
> I think Phil came up with the idea to try to focus on the components that
> we are able to maintain and put all other stuff to dormant. Here is the
> list of components that I think really are proper:
> 
> - CLI
> - Codec
> - Collections
> - Compress
> - Configuration
> - CSV
> - Daemon
> - DBCP (?)
> - Email
> - Functor
> - Imaging (?)
> - IO
> - JCI
> - Lang
> - Logging
> - Math
> - Net
> - Pool (?)
> - Proxy
> - SCXML (after recent interest)
> - VFS
> - Weaver
> 
> All other stuff can go dormant because there is currently nobody who
> maintains it. Still a pretty long list. Thoughts? Anything missing?

I would like to get another release of BeanUtils out because there is a
dependency to the current work on Configuration. After that I am
interested in working on BeanUtils2 (in the sandbox).

Oliver

> 
> Benedikt
> 


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

Re: [VOTE] Move Apache Commons to Git for SCM...

2013-10-10 Thread Oliver Heger

+1 to git in general, however, I also prefer the approach to do the move
in a more careful way, i.e. experimenting with single components first.

Oliver

Am 10.10.2013 16:50, schrieb James Carman:
> All,
> 
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
> 
> +1 - yes, move to Git
> -1 - no, do not move to Git
> 
> The vote will be left open for 72 hours.  Go!
> 
> -
> 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] Move Apache Commons to Git for SCM...

2013-10-11 Thread Oliver Heger

Am 11.10.2013 02:10, schrieb Phil Steitz:
> 
> 
>> On Oct 10, 2013, at 4:41 PM, Olivier Lamy  wrote:
>>
>> Even I like git and use it daily, I will vote +0,5.
>>
>> Why other apache projects need to have their own commons-csv
>> repackaged release? why tomcat need to use a svn:external on dbcp
>> instead of a released version? why servicemix need to repackage all
>> commons jar to have proper osgi bundles?
>>
>> I simply believe moving to git won't fix those problems about the too
>> complicated release process which scare folks here to try releasing a
>> component!!
>> So no release happen at the end
>>
> I agree that the release process is certainly a problem; but the big problem 
> IMO is just too many components for too few really active committers.  Once 
> we actually have something ready to release, we have generally been able to 
> fumble our way through the process.  The problem is getting there.  
> 
> I think the best thing we can do is focus on getting some things ready for 
> release.  I will help on pool, DBCP, math.  I won't rob Mark of the oppty to 
> rm pool2, but will help ;). All are welcome to join the fun cleaning up the 
> docs and other loose ends on that and then dbcp2.  
> 
> Who wants to step up to drive some other things  to release?
I plan to prepare a release of BeanUtils soon.

Oliver

> 
> Phil
>>
>>> On 11 October 2013 01:50, James Carman  wrote:
>>> All,
>>>
>>> We have had some great discussions about moving our SCM to Git.  I
>>> think it's time to put it to a vote.  So, here we go:
>>>
>>> +1 - yes, move to Git
>>> -1 - no, do not move to Git
>>>
>>> The vote will be left open for 72 hours.  Go!
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>>
>> -- 
>> Olivier Lamy
>> Ecetera: http://ecetera.com.au
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
> 
> -
> 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: [BeanUtils] Next release WAS [VOTE] Move Apache Commons to Git for SCM...

2013-10-11 Thread Oliver Heger

Am 11.10.2013 22:01, schrieb Benedikt Ritter:
> 2013/10/11 Oliver Heger 
> 
>> Am 11.10.2013 02:10, schrieb Phil Steitz:
>>>
>>>
>>>> On Oct 10, 2013, at 4:41 PM, Olivier Lamy  wrote:
>>>>
>>>> Even I like git and use it daily, I will vote +0,5.
>>>>
>>>> Why other apache projects need to have their own commons-csv
>>>> repackaged release? why tomcat need to use a svn:external on dbcp
>>>> instead of a released version? why servicemix need to repackage all
>>>> commons jar to have proper osgi bundles?
>>>>
>>>> I simply believe moving to git won't fix those problems about the too
>>>> complicated release process which scare folks here to try releasing a
>>>> component!!
>>>> So no release happen at the end
>>>>
>>> I agree that the release process is certainly a problem; but the big
>> problem IMO is just too many components for too few really active
>> committers.  Once we actually have something ready to release, we have
>> generally been able to fumble our way through the process.  The problem is
>> getting there.
>>>
>>> I think the best thing we can do is focus on getting some things ready
>> for release.  I will help on pool, DBCP, math.  I won't rob Mark of the
>> oppty to rm pool2, but will help ;). All are welcome to join the fun
>> cleaning up the docs and other loose ends on that and then dbcp2.
>>>
>>> Who wants to step up to drive some other things  to release?
>> I plan to prepare a release of BeanUtils soon.
>>
> 
> Good to hear. There is a lot to do. I started generification a while back.
> If you like you can join #asfcommons and we can have a talk about BU.

I did not look into the open issues so far. I would rather take a more
minimalistic approach, i.e. pushing out version 1.9 with what is
currently there and then put more energy in BeanUtils2.

Oliver

> 
> Benedikt
> 
> 
>>
>> Oliver
>>
>>>
>>> Phil
>>>>
>>>>> On 11 October 2013 01:50, James Carman 
>> wrote:
>>>>> All,
>>>>>
>>>>> We have had some great discussions about moving our SCM to Git.  I
>>>>> think it's time to put it to a vote.  So, here we go:
>>>>>
>>>>> +1 - yes, move to Git
>>>>> -1 - no, do not move to Git
>>>>>
>>>>> The vote will be left open for 72 hours.  Go!
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>>
>>>>
>>>> --
>>>> Olivier Lamy
>>>> Ecetera: http://ecetera.com.au
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>
>>> -
>>> 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: Site Builds and Release Votes

2013-10-13 Thread Oliver Heger

Am 13.10.2013 20:51, schrieb Henri Yandell:
> On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe wrote:
> 
>> Le 13/10/2013 17:35, Stefan Bodewig a écrit :
>>> Hi all
>>>
>>> in the recent release vote for Compress Gary and I had very different
>>> opinions on the importance of the site build for release candidates.
>>>
>>> On 2013-10-13, Gary Gregory wrote:
>>>
 On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig 
>> wrote:
>>>
> I have not created a RC website as the only difference to the current
> website would be the download page and the version number - and I'd
> immediately change the site after the release to include the release
> date anyway.
>>>
 - Using the live site for the RC is a bad idea IMO because the source
 will have to be changed to update the version, for example "The
 current release is 1.5." and "Commons Compress 1.5 requires Java 5"
 and who knows what else will have to be changed. This means that what
 is in the RC is NOT building the 1.6 site, it is building a SNAPSHOT
 site.
>>>
>>> To me creating the site is one of the completely unnecessary steps to
>>> perform when cutting a release candidate.  Building and uploading the
>>> site takes something > 15 minutes to me.  So far I have never published
>>> the RC site when the RC was accepted but rather created a new site build
>>> that contained the release date, updated the changes report with a
>>> placeholder for the next release and so on.
>>>
>>> We can - and should - update the site outside of any release anyway, so
>>> to me the site content is completely irrelevant when I evaluate
>>> releases.
>>>
>>> I'll admit that this mirrors my suspicion that nobody looks at the site
>>> build contained in the binary release anyway.  People use their
>>> dependency manager of choice and the online docs in my experience.
>>>
>>> How do others think about the release candidate site build?
>>
>> I agree the site build is orthogonal to release.
>> The main thing we release is source code. Then on top of that we add
>> some binaries, but it is already a by-product. The site itself is not
>> something we should consider to be in the scope of the release.
>>
>>
>  Agreed - the site build as a whole is for informative purposes during a
> vote. If there are any bugs in a site, they never block the release as they
> can be fixed out of band.
> 
> The only items that should be blockers on the site build are those included
> in the distribution. I thought that was only the javadoc instead of the
> whole site? I'd definitely consider a bad javadoc to be something we should
> consider a new RC for, though it would depend on the severity. The cost of
> building a new RC is greater than fixing a typo in javadoc.
> 
> Hen
> 
But shouldn't the site at least be in sync with a new release regarding
stuff like descriptions of new features, updated user guides, etc.?

It is part of the release process to deploy the site. So it should not
be too much additional effort to prepare this for an RC.

I remember that in past we also had problems with sites that were
updated during development. Then we received bug reports because
features advertised in the documentation were not available in the
released version. So I cannot agree to the statement that a site update
can be done at any time.

Oliver


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

Re: [VOTE] Release Commons Compress 1.6

2013-10-13 Thread Oliver Heger

The artifacts look good, the build works fine with Java 1.7 on Windows
7. I tried to build with Java 1.5, but got:

Tests in error:

SevenZTestCase.testSevenZArchiveCreationUsingLZMA2:37->testSevenZArchiveCreati
on:59 ╗ OutOfMemory
  XZTestCase.testXZCreation:44 ╗ OutOfMemory Java heap space

Tests run: 374, Failures: 0, Errors: 2, Skipped: 0

ISTR that I had similar problems with other [compress] releases, so I
don't consider this as blocking.

However, I found the following problems:

The title in the release notes says "Apache Commons Compress 1.5 RELEASE
NOTES"; it refers to the old version. I think, this requires another RC.

The RC was built using Java 1.6.0_27. Does this version already contain
the Javadoc security fix?

When I build the site locally, I get a different clirr report showing 9
errors because some public methods have been made final.

Oliver

Am 13.10.2013 07:31, schrieb Stefan Bodewig:
> Hi
> 
> since Compress 1.5 we've fixed a few bugs but most notably added
> read-only support for LZMA standalone, uncompressed ARJ and full support
> for 7z.
> 
> I have not created a RC website as the only difference to the current
> website would be the download page and the version number - and I'd
> immediately change the site after the release to include the release
> date anyway.
> 
> Foo 1.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/
> (svn revision 3254)
> 
>   Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-167/org/apache/commons/commons-compress/1.6/
> 
>   Details of changes since 1.5 are in the release notes:
> 
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/RELEASE-NOTES.txt
> 
>   The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC1/
> (svn revision 1531616)
> 
>   Site:
> http://commons.apache.org/compress/
> 
>   Clirr Report (compared to 1.5):
> http://commons.apache.org/compress/clirr-report.html
> 
>   RAT Report:
> http://commons.apache.org/compress/rat-report.html
> 
>   KEYS:
>   http://www.apache.org/dist/commons/KEYS
>   
>   Please review the release candidate and vote.
>   This vote will close no sooner that 72 hours from now, i.e. after 0530
>   GMT 16-October 2013 - given that I'll be traveling the second half of
>   this week I'd rather expect the release to happen next Saturday.
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
>   Thanks!
> 
> -
> 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: [BeanUtils] Next release WAS [VOTE] Move Apache Commons to Git for SCM...

2013-10-13 Thread Oliver Heger

Am 11.10.2013 22:55, schrieb Benedikt Ritter:
> 2013/10/11 Oliver Heger 
> 
>> Am 11.10.2013 22:01, schrieb Benedikt Ritter:
>>> 2013/10/11 Oliver Heger 
>>>
>>>> Am 11.10.2013 02:10, schrieb Phil Steitz:
>>>>>
>>>>>
>>>>>> On Oct 10, 2013, at 4:41 PM, Olivier Lamy  wrote:
>>>>>>
>>>>>> Even I like git and use it daily, I will vote +0,5.
>>>>>>
>>>>>> Why other apache projects need to have their own commons-csv
>>>>>> repackaged release? why tomcat need to use a svn:external on dbcp
>>>>>> instead of a released version? why servicemix need to repackage all
>>>>>> commons jar to have proper osgi bundles?
>>>>>>
>>>>>> I simply believe moving to git won't fix those problems about the too
>>>>>> complicated release process which scare folks here to try releasing a
>>>>>> component!!
>>>>>> So no release happen at the end
>>>>>>
>>>>> I agree that the release process is certainly a problem; but the big
>>>> problem IMO is just too many components for too few really active
>>>> committers.  Once we actually have something ready to release, we have
>>>> generally been able to fumble our way through the process.  The problem
>> is
>>>> getting there.
>>>>>
>>>>> I think the best thing we can do is focus on getting some things ready
>>>> for release.  I will help on pool, DBCP, math.  I won't rob Mark of the
>>>> oppty to rm pool2, but will help ;). All are welcome to join the fun
>>>> cleaning up the docs and other loose ends on that and then dbcp2.
>>>>>
>>>>> Who wants to step up to drive some other things  to release?
>>>> I plan to prepare a release of BeanUtils soon.
>>>>
>>>
>>> Good to hear. There is a lot to do. I started generification a while
>> back.
>>> If you like you can join #asfcommons and we can have a talk about BU.
>>
>> I did not look into the open issues so far. I would rather take a more
>> minimalistic approach, i.e. pushing out version 1.9 with what is
>> currently there and then put more energy in BeanUtils2.
>>
>>
> I looked through most issues. There were three categories:
> - issues I was unable to fix
> - issues I was unable to reproduce
> - issues I was unable to understand because they were written in some
> strange asian-english mixture
> 
> But we can have another iteration and talk about the things.
> Generics can be removed if you want to do a minimal release.
It is certainly annoying to have all these generics warnings in the
code, especially if there are already some classes that have been
adapted. Do you remember roughly how many classes you did rework when
you started with generification?

I guess I will start an attempt to generify some classes and see how far
this gets and how easy or complicated it is. Then we can decide whether
we use generics or not.

Oliver

> 
> BU2 is a hole different story. It's more like a prototype. But I'd love to
> start work on it again.
> 
> 
>> Oliver
>>
>>>
>>> Benedikt
>>>
>>>
>>>>
>>>> Oliver
>>>>
>>>>>
>>>>> Phil
>>>>>>
>>>>>>> On 11 October 2013 01:50, James Carman 
>>>> wrote:
>>>>>>> All,
>>>>>>>
>>>>>>> We have had some great discussions about moving our SCM to Git.  I
>>>>>>> think it's time to put it to a vote.  So, here we go:
>>>>>>>
>>>>>>> +1 - yes, move to Git
>>>>>>> -1 - no, do not move to Git
>>>>>>>
>>>>>>> The vote will be left open for 72 hours.  Go!
>>>>>>>
>>>>>>> -
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Olivier Lamy
>>>>>> Ecetera: http://ecetera.com.au
>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>
>>>>>
>>>>> -
>>>>> 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: [BeanUtils] Next release WAS [VOTE] Move Apache Commons to Git for SCM...

2013-10-13 Thread Oliver Heger

Am 13.10.2013 22:08, schrieb Benedikt Ritter:
> 2013/10/13 Oliver Heger 
> 
>> Am 11.10.2013 22:55, schrieb Benedikt Ritter:
>>> 2013/10/11 Oliver Heger 
>>>
>>>> Am 11.10.2013 22:01, schrieb Benedikt Ritter:
>>>>> 2013/10/11 Oliver Heger 
>>>>>
>>>>>> Am 11.10.2013 02:10, schrieb Phil Steitz:
>>>>>>>
>>>>>>>
>>>>>>>> On Oct 10, 2013, at 4:41 PM, Olivier Lamy  wrote:
>>>>>>>>
>>>>>>>> Even I like git and use it daily, I will vote +0,5.
>>>>>>>>
>>>>>>>> Why other apache projects need to have their own commons-csv
>>>>>>>> repackaged release? why tomcat need to use a svn:external on dbcp
>>>>>>>> instead of a released version? why servicemix need to repackage all
>>>>>>>> commons jar to have proper osgi bundles?
>>>>>>>>
>>>>>>>> I simply believe moving to git won't fix those problems about the
>> too
>>>>>>>> complicated release process which scare folks here to try releasing
>> a
>>>>>>>> component!!
>>>>>>>> So no release happen at the end
>>>>>>>>
>>>>>>> I agree that the release process is certainly a problem; but the big
>>>>>> problem IMO is just too many components for too few really active
>>>>>> committers.  Once we actually have something ready to release, we have
>>>>>> generally been able to fumble our way through the process.  The
>> problem
>>>> is
>>>>>> getting there.
>>>>>>>
>>>>>>> I think the best thing we can do is focus on getting some things
>> ready
>>>>>> for release.  I will help on pool, DBCP, math.  I won't rob Mark of
>> the
>>>>>> oppty to rm pool2, but will help ;). All are welcome to join the fun
>>>>>> cleaning up the docs and other loose ends on that and then dbcp2.
>>>>>>>
>>>>>>> Who wants to step up to drive some other things  to release?
>>>>>> I plan to prepare a release of BeanUtils soon.
>>>>>>
>>>>>
>>>>> Good to hear. There is a lot to do. I started generification a while
>>>> back.
>>>>> If you like you can join #asfcommons and we can have a talk about BU.
>>>>
>>>> I did not look into the open issues so far. I would rather take a more
>>>> minimalistic approach, i.e. pushing out version 1.9 with what is
>>>> currently there and then put more energy in BeanUtils2.
>>>>
>>>>
>>> I looked through most issues. There were three categories:
>>> - issues I was unable to fix
>>> - issues I was unable to reproduce
>>> - issues I was unable to understand because they were written in some
>>> strange asian-english mixture
>>>
>>> But we can have another iteration and talk about the things.
>>> Generics can be removed if you want to do a minimal release.
>> It is certainly annoying to have all these generics warnings in the
>> code, especially if there are already some classes that have been
>> adapted. Do you remember roughly how many classes you did rework when
>> you started with generification?
>>
> 
> None, I just changes the language level. I wanted to review all open issues
> before starting with the generification, because the changes all over the
> place will make appling patches very difficult. I think it was Sebb who
> started, before I told him my intention.
> 
> 
>>
>> I guess I will start an attempt to generify some classes and see how far
>> this gets and how easy or complicated it is. Then we can decide whether
>> we use generics or not.
> 
> 
> IMHO another release of BU1 should have generics. If it is to difficult we
> should better invest the time to work on BU2.

Yes, I also prefer having generics.

However, there is a dependency of [configuration] 2.0 and a new feature
of BU, so I really need to push out a release.

Oliver

> 
> 
>>
>> Oliver
>>
>>>
>>> BU2 is a hole different story. It's more like a prototype. But I'd love
>> to
>>> start work on it again.
>>>
>>>
>>>> Oliver
>>>>
>>>>>
>>>>> Benedikt
>>>>>
>>>>>
>>>&

Re: [VOTE] Release Commons Compress 1.6

2013-10-14 Thread Oliver Heger

Am 14.10.2013 06:11, schrieb Stefan Bodewig:
> On 2013-10-13, Oliver Heger wrote:
> 
>> The artifacts look good, the build works fine with Java 1.7 on Windows
>> 7. I tried to build with Java 1.5, but got:
> 
>> Tests in error:
> 
>> SevenZTestCase.testSevenZArchiveCreationUsingLZMA2:37->testSevenZArchiveCreati
>> on:59 ╗ OutOfMemory
>>   XZTestCase.testXZCreation:44 ╗ OutOfMemory Java heap space
> 
>> Tests run: 374, Failures: 0, Errors: 2, Skipped: 0
> 
>> ISTR that I had similar problems with other [compress] releases, so I
>> don't consider this as blocking.
> 
> I don't recall it, but XZ is pretty heavy on GC pressure.  Given that
> our XZ implementation is a very thin layer on top of XZ for Java there
> wouldn't be anything we could do - apart from increasing the heap size
> for the tests - anyway.
> 
>> The title in the release notes says "Apache Commons Compress 1.5 RELEASE
>> NOTES"; it refers to the old version. I think, this requires another RC.
> 
> Ouch.
> 
>> The RC was built using Java 1.6.0_27. Does this version already contain
>> the Javadoc security fix?
> 
> The javadoc plugin used by the Commons Parent took care of it.
> 
>> When I build the site locally, I get a different clirr report showing 9
>> errors because some public methods have been made final.
> 
> Strange.  Why would Clirr create different reports?  We're supposed to
> be using the same versions of Clirr, aren't we?
> 
> Can you make your Clirr reports available so we can evaluate whether we
> should fix those additional errors in a second RC?

I have no clue why Clirr produces different results for me, and the
errors it reports look indeed a bit strange. I uploaded my results of
mvn site:site (using JDK 1.7 - maybe this is the reason for the
difference?) to [1]

Oliver

[1] http://people.apache.org/~oheger/compress-site/

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


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

Re: svn commit: r1532068 - /commons/proper/beanutils/branches/java5/src/main/java/org/apache/commons/beanutils/DynaBeanMapDecorator.java

2013-10-15 Thread Oliver Heger

Despite the fact that this is an interesting problem, do generic
parameters really make sense here? The map provided by the decorator is
in fact a Map. But because of backwards compatibility
these parameter types cannot be used. Would it improve situation to add
type parameters to the decorator class?

Oliver

Am 15.10.2013 21:30, schrieb Matt Benson:
> Or, more directly/formally, at:
> http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.4
> 
> Matt
> 
> 
> On Tue, Oct 15, 2013 at 2:26 PM, Matt Benson  wrote:
> 
>> We may be talking about different things.  I think I am talking about type
>> variable bounds declarations; I'm not 100% sure of the context in which
>> your suggestion was offered.  The restriction on type bounds is documented
>> at [1].
>>
>> Matt
>> [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.9
>>
>>
>>
>>
>> On Tue, Oct 15, 2013 at 2:10 PM, sebb  wrote:
>>
>>> On 15 October 2013 18:46, Matt Benson  wrote:
 Does that work?
>>>
>>> Let's try it?
>>>
 Seems I recently encountered the types after & having to
 be interfaces.
>>>
>>> Why should that be? Is that documented anywhere?
>>>
 Matt


 On Tue, Oct 15, 2013 at 12:31 PM, sebb  wrote:

> On 15 October 2013 18:14, Benedikt Ritter  wrote:
>> Hi Oliver,
>>
>> why can't we implement Map and make the decorator a generic
>>> type
> here?
>
> Also, I believe it is possible to define a generic parameter as
> String, but default to Object as the erased type.
> This would improve the source code checking without compromising
> binary compatibility.
>
> The syntax is something like
>
> Set
>
>> Benedikt
>>
>>
>> 2013/10/14 
>>
>>> Author: oheger
>>> Date: Mon Oct 14 20:27:46 2013
>>> New Revision: 1532068
>>>
>>> URL: http://svn.apache.org/r1532068
>>> Log:
>>> Added generics.
>>>
>>> Modified:
>>>
>>>
>
>>> commons/proper/beanutils/branches/java5/src/main/java/org/apache/commons/beanutils/DynaBeanMapDecorator.java
>>>
>>> Modified:
>>>
>
>>> commons/proper/beanutils/branches/java5/src/main/java/org/apache/commons/beanutils/DynaBeanMapDecorator.java
>>> URL:
>>>
>
>>> http://svn.apache.org/viewvc/commons/proper/beanutils/branches/java5/src/main/java/org/apache/commons/beanutils/DynaBeanMapDecorator.java?rev=1532068&r1=1532067&r2=1532068&view=diff
>>>
>>>
>
>>> ==
>>> ---
>>>
>
>>> commons/proper/beanutils/branches/java5/src/main/java/org/apache/commons/beanutils/DynaBeanMapDecorator.java
>>> (original)
>>> +++
>>>
>
>>> commons/proper/beanutils/branches/java5/src/main/java/org/apache/commons/beanutils/DynaBeanMapDecorator.java
>>> Mon Oct 14 20:27:46 2013
>>> @@ -16,14 +16,13 @@
>>>   */
>>>  package org.apache.commons.beanutils;
>>>
>>> -import java.util.Map;
>>> -import java.util.List;
>>>  import java.util.ArrayList;
>>> -import java.util.Set;
>>> -import java.util.HashSet;
>>> -import java.util.Iterator;
>>>  import java.util.Collection;
>>>  import java.util.Collections;
>>> +import java.util.HashSet;
>>> +import java.util.List;
>>> +import java.util.Map;
>>> +import java.util.Set;
>>>
>>>  /**
>>>   * Decorates a {@link DynaBean} to provide Map
>>> behaviour.
>>> @@ -66,15 +65,18 @@ import java.util.Collections;
>>>   *and values() methods create an
>>> unmodifiable
>>>   *Set and it does not support the Map's
>>> clear()
>>>   *and remove() operations.
>>> + * For reasons of backwards compatibility, the generic types of
>>> this
>>> + *{@code Map} implementation are {@code }.
>>> However,
>>> the
>>> + *keys of the map are typically strings.
>>>   *
>>>   * @since BeanUtils 1.8.0
>>>   * @version $Id$
>>>   */
>>> -public class DynaBeanMapDecorator implements Map {
>>> +public class DynaBeanMapDecorator implements Map {
>>>
>>>  private final DynaBean dynaBean;
>>>  private final boolean readOnly;
>>> -private transient Set keySet;
>>> +private transient Set keySet;
>>>
>>>  // --- Constructors
> --
>>>
>>> @@ -181,9 +183,9 @@ public class DynaBeanMapDecorator implem
>>>   * @return An unmodifiable set of the DynaBean
>>>   * property name/value pairs
>>>   */
>>> -public Set entrySet() {
>>> +public Set> entrySet() {
>>>  DynaProperty[] properties = getDynaProperties();
>>> -Set set = new HashSet(properties.length);
>>> +Set> set = new
>>> HashSet>(properties.length);
>>>  for (int i = 0; i < properties.length; i++) {
>>>  String

< 1 2 3 4 5 6 7 8 9 10 >

201 - 300 of 1045 matches

Mail list logo