Re: [collections] Null-safe addAll(final Collection collection, final C... elements) [WAS] CollectionUtils not null-safe

[Dave Brosius]

I'd be much more  happy it the method was added, as something like

safeAddAll

so you knew when you were using it, but i agree then your api starts to 
bloat pretty badly.



CollectionUtils.isEmpty checking for null makes sense. You are 
explicitly using the method to check for null as a condition.



addAll doesn't say that to me when i use it. One argument for your 
proposal is that there really is no reason to use Collections.addAll


over myRealCollection.addAll(x);, so perhaps adding this null check 
gives it value.



Anyway, just my two cents. I have never used this method, so it doesn't 
effect me, so if in the end this is what you want to do, i guess it's 
ok, just showing the other side.



On 05/20/2018 11:02 AM, Gary Gregory wrote:

Shall we do this in a more pragmatic fashion? One method at a time. Let's
start with changing:

 /**
  * Adds all elements in the array to the given collection.
  *
  * @param   the type of object the {@link Collection} contains
  * @param collection  the collection to add to, must not be null
  * @param elements  the array of elements to add, must not be null
  * @return {@code true} if the collection was changed, {@code false}
otherwise
  * @throws NullPointerException if the collection or array is null
  */
 public static  boolean addAll(final Collection collection, final
C... elements) {
 boolean changed = false;
 for (final C element : elements) {
 changed |= collection.add(element);
 }
 return changed;
 }

to:

 /**
  * Adds all elements in the array to the given collection.
  *
  * @param   the type of object the {@link Collection} contains
  * @param collection  the collection to add to
  * @param elements  the array of elements to add
  * @return {@code true} if the collection was changed, {@code false}
otherwise
  */
 public static  boolean addAll(final Collection collection, final
C... elements) {
 boolean changed = false;
 if (collection != null && elements != null) {
 for (final C element : elements) {
 changed |= collection.add(element);
 }
 }
 return changed;
 }

Which makes the method not blow up when either inputs is null.

Gary

On Sat, May 19, 2018 at 10:15 PM, Dave Brosius 
wrote:


This protection concept sounds perfectly rational, until you think of
other obvious things that do similar things to protect the coder.

myLong.equals(myString) doesn't throw an exception for instance, it just
return false.

but then you never know that you have a problem in your code and just
blindly go along using it seemingly working fine.

Similarly, given that collection.addAll(null) throws, papering over that
fact with CollectionUtils might do more harm than good.




On 05/19/2018 09:10 PM, Gary Gregory wrote:


On Sat, May 19, 2018 at 4:47 AM, sebb  wrote:

On 18 May 2018 at 20:34, Gary Gregory  wrote:

Hi All:

A lot of methods in CollectionUtils are not null-safe and are documented


as


such in Javadoc with throwing NPEs.

I'd like to change that.


To what?

For example, this should not cause an NPE:

collectionA = new ArrayList();
CollectionUtils.addAll(collectionA, (Integer[]) null);

Gary

The change is behavioral and BC would be preserved.

Thoughts?


It depends on the method whether a null parameter makes sense or not.
In some cases it may be confusing if null is accepted.
And what is meant by a null parameter.

In any case, any such changes need a big warning in the release notes.

Gary
-
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: [collections] CollectionUtils not null-safe

[Dave Brosius]

This protection concept sounds perfectly rational, until you think of 
other obvious things that do similar things to protect the coder.


myLong.equals(myString) doesn't throw an exception for instance, it just 
return false.


but then you never know that you have a problem in your code and just 
blindly go along using it seemingly working fine.


Similarly, given that collection.addAll(null) throws, papering over that 
fact with CollectionUtils might do more harm than good.




On 05/19/2018 09:10 PM, Gary Gregory wrote:

On Sat, May 19, 2018 at 4:47 AM, sebb  wrote:


On 18 May 2018 at 20:34, Gary Gregory  wrote:

Hi All:

A lot of methods in CollectionUtils are not null-safe and are documented

as

such in Javadoc with throwing NPEs.

I'd like to change that.

To what?


For example, this should not cause an NPE:

collectionA = new ArrayList();
CollectionUtils.addAll(collectionA, (Integer[]) null);

Gary


The change is behavioral and BC would be preserved.

Thoughts?

It depends on the method whether a null parameter makes sense or not.
In some cases it may be confusing if null is accepted.
And what is meant by a null parameter.

In any case, any such changes need a big warning in the release notes.


Gary

-
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] breaking changes

[Dave Brosius]

i'm not sure i follow, don't we already have breaking changes for which 
we've decided to change bump the version?



On 03/29/2018 11:00 PM, Paul King wrote:

Just to clarify, when I said "It's built with gradle and uses Ant", I
mean our build is gradle based and our call of Bridger uses Ant.
Bridger itself is built with Maven.

On Fri, Mar 30, 2018 at 12:20 PM, Paul King  wrote:

In the Groovy build we do this using Bridger
(https://github.com/dmlloyd/bridger). It's built with gradle (and uses
Ant). They have a Maven plugin but I haven't used it.

In our build we have this:

compileJava {
 doLast {
 ant.java(classname:'org.jboss.bridger.Bridger', classpath:
rootProject.configurations.tools.asPath, outputproperty: 'stdout') {
 arg(value:
"${sourceSets.main.java.outputDir.canonicalPath}/org/codehaus/groovy/runtime/DefaultGroovyMethods.class")
 }
 ant.echo('Bridger: ' + ant.properties.stdout)
 }
}

And in the relevant source file we have a small number of $$bridge
methods like this one:

public static  List withDefault$$bridge(List self, Closure init) {
 return withDefault(self, init);
}

to match the original methods we are duplicating, e.g.:

public static  ListWithDefault withDefault(List self,
Closure init) {
 // ... code here ...
}

Cheers, Paul.

On Fri, Mar 30, 2018 at 9:52 AM, Peter Burka  wrote:

This could be solved if it were possible to force javac to generate bridge
methods. There's an extension which would allow that here:
https://github.com/infradna/bridge-method-injector, but I suspect it would
complicate the build process quite a bit.

On Thu, Mar 29, 2018 at 4:48 PM sebb  wrote:


The return type is part of the method signature that Java uses to find
resolve references.

Even changing from void to non-void will cause binary incompatibility.
(Source-wise, that's fine)

On 29 March 2018 at 18:20, Gary Gregory  wrote:

Yep, that's no good. I'll revert.

Gary

On Thu, Mar 29, 2018 at 10:16 AM, Paul King 
wrote:


I haven't looked into the IteratorUtils class at all but it's easy to
show binary incompatibility when changing the return type.
Compile this "library" class:

import java.util.ArrayList;
import java.util.List;

public class Lib {
 List getMyList() {
 return new ArrayList();
 }
}

Now compile this user of the library:

import java.util.List;

public class Main {
 public static void main(String[] args) {
 doit(new Lib().getMyList());
 }

 private static void doit(List list) {
 System.out.println("list is: " + list);
 }
}


Ensure it all works:


java -cp path_to_lib Main

Should output:

List is: []

Now change the Lib class to return ArrayList instead of List and
recompile just the Lib class (i.e. importantly don't recompile Main).

Now if you try:


java -cp path_to_lib Main

you should see:

Exception in thread "main" java.lang.NoSuchMethodError:
Lib.getMyList()Ljava/util/List;
 at Main.main(Main.java:5)

Cheers, Paul.

On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory 
wrote:

Can you show how older code would not function. Aside from using

reflection.

Gary

On Thu, Mar 29, 2018, 09:03 Claude Warren  wrote:


if we are using semantic numbering would this not cause a major

revision

change as older code will no longer function?

Claude

On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory <

garydgreg...@gmail.com>

wrote:


Hi All:

Updating Commons Collections' commons-parent from version 43 to 45

causes

the build to fail due to the use of japicmp which reports:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site)

on

project commons-collections4: Error generating
japicmp-maven-plugin:0.11.0:cmp-report report: Failed to generate

report:

Breaking the build because there is at least one incompatibility:
org.apache.commons.collections4.IteratorUtils.

peekingIterator(java.util.

Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons.
collections4.IteratorUtils.pushbackIterator(java.util.
Iterator):METHOD_RETURN_TYPE_CHANGED
-> [Help 1]

This is caused by:

- [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator

signature to

return PushbackIterator.
- [COLLECTIONS-675] Modify IteratorUtils.peekingIterator signature

to

return PeekingIterator.

Which are reasonable changes IMO.

Does anyone object to these changes and adding exceptions to allow

japicmp

to
not fail the build?

Thank you,
Gary




--
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren


-
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



---

[beanutils] release?

[Dave Brosius]

Given the lack of impetus around doing anything more grand with 
beanutils, can we put out the current state of beanutils as 2.0 so we 
can get rid of the old commons-collections dependency, and then if folks 
would like, we can think about moving on with what's on the alternative 
branch in the future?


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

Re: [Net] When should we update net from Java 6 to 7?

[Dave Brosius]

I agree with this completely, it's also why moving to git is so important.


On 01/13/2018 08:33 AM, Pascal Schumacher wrote:

Am 13.01.2018 um 01:31 schrieb Gilles:

On Fri, 12 Jan 2018 21:51:58 +0100, Pascal Schumacher wrote:

imho we should drop support for java 6 and make every component java 7+


Why?


Imho old java versions discourage contributions. Java 7 was released 
in 2011 8 (and Java 8 in 2014), so there is an increasing number of 
developers who never used older versions. Why force volunteers to work 
harder to stay Java 6 compatible when volunteering is supposed to be fun?


Support for Java 6 (and even Java 7) is decreasing everywhere. E.g. 
current maven versions (and maven plugin versions) required Java 7 
(plugin versions supporting Java 6 often do not work on Java 9). 
Current travis VMs do not support build on Java 6...


Just my two cents.

Cheers,
Pascal

-
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] Toward 2.0.0

[Dave Brosius]

beanutils 3 exposed 'FastHashMap' which was a commons collections 3 data 
structure in it's own interface. That went away in commons collections 
4, and so i modified the beanutils 4 interface to use 
ConcurrentHashMaps. Thus the need for a package rename.



On 12/28/2017 04:56 PM, sebb wrote:

On 28 December 2017 at 19:49, Gary Gregory  wrote:

Hi All,

- BeanUtils now has a new package o.a.c.beanutils2.
- BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
which caused the above.

What more do we want before releasing 2.0.0?

Updating from BU 1.x to 2.x should be "simple" for now: Just update your
imports.

Surely there must be some other breaking changes otherwise there would
be no need to change the package name?


Thoughts?

Gary

-
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: [BCEL] thread safety

[Dave Brosius]

The main issue was the static Repository, but instance based 
Repositories are available now.



On 12/11/2017 11:26 AM, Torsten Curdt wrote:

It's been a looong time since I worked on BCEL and my memories might serve
me wrong but I think thread safety is something that should not necessarily
happen on the BCEL level. BCEL holds a lot of state. Making all that
threadsafe - I'd like to see the use cases first as it might come at a
cost. BCEL was even using statics to store state - I would suggest to fix
that first (if it's still the case).

But anyway - my 2 cents from some vague memories.

cheers,
Torsten

On Mon, Dec 11, 2017 at 4:38 PM, Gary Gregory 
wrote:


Thread safety or lack thereof seems to be a recurring theme in BCEL.

Is anyone available to take a closer look at what it would take to update
the code with thread safety in mind?

Gary




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

Re: [VOTE][LAZY] Migrate Apache Commons BCEL to git

[Dave Brosius]

+1


On 10/21/2017 10:19 AM, Gary Gregory wrote:

+1

Gary

On Oct 21, 2017 02:21, "Benedikt Ritter"  wrote:

Hello,

I’d like to move Apache Commons BCEL codebase to git, so I’m calling a vote
by lazy consensus. If nobody objects within the next 72 hours this vote
passes and I will start with the migration.

This vote will be open until at least 24-October-2017, 10:30 CEST (UTC+2).

Regards,
Benedikt
-
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][Math] New component: "Commons Geometry"?

[Dave Brosius]

So volunteers? Gary, Emmanuel, others?? are you up to doing this?


On 08/31/2017 06:29 PM, Gary Gregory wrote:

On Thu, Aug 31, 2017 at 4:28 PM, Emmanuel Bourg  wrote:


Le 31/08/2017 à 23:33, Gilles a écrit :


it's a pity we cannot meet in person to sort all those issues

Hum, maybe with a few beers you'll be easier to convince ;)



I'm not against you modularizing CM, I'm against me doing it
just because you "think" it's a better approach to the
(management) problems which I've been describing for at least
two years (and some more).

I understand your point of view, you don't want to spent a lot of time
modularizing CM, dealing with parts of the code you are not comfortable
with and delaying the release of code you really care about. That's fair
and I agree this shouldn't be forced upon you.

The good news is you don't actually have to refactor *all* of CM as a
multi-module project right now. Start with a mostly empty branch
containing just a couple of modules you like and release them. And you
progressively bring more modules after each release from the old CM
branch. That's equivalent to the creation of multiple components (you
cherry-pick the code that you want, and release it when ready), and you
keep the lightweight management of a single component.


That sounds like a nice iterative approach.

Gary



Emmanuel Bourg

-
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][Math] New component: "Commons Geometry"?

[Dave Brosius]

>> I get that what you are really trying to do is kill Commons Math off 
piece by piece. I just don’t agree with doing that.



This is ridiculous. Giles is the primary person trying to keep some 
semblance of commons-math-like-stuff alive. He has asserted that there 
is no way he can maintain all of commons-math, and no one else is really 
all that interested.  Time has proven he is right.


Given he is trying his best to keep code going, and actually the one 
doing the work, perhaps we should be a little bit less offensive about 
trying to shut him down.


--dave

On 08/21/2017 01:52 PM, Ralph Goers wrote:

On Aug 21, 2017, at 4:39 AM, Gilles  wrote:

On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote:

Am 20.08.2017 um 23:11 schrieb Ralph Goers :

I have to agree with Jochen and am -1 to this proposal. I have stated before 
that I don’t want to see Commons become the placeholder for all the Math 
related components. If Math has stuff that can’t be maintained then create a 
MathLegacy project in the sandbox and move the stuff there.

I’ve also already argued in that direction.

I gave technical arguments in favour of the proposal (cf. first
post in this thread).

People opposing it give none.
A sudden "allergy" of some PMC members to "math"-related code
does not warrant rejecting non-obsolete code.[1]

A good start would be to answer this question: Why is it bad (or
worse than the current situation) to have this "new" component?

Technical arguments are not required since this is basically a housekeeping 
issue.

I’m not sure why I would answer your last question since you are clearly going 
to have a different opinion. But many of us believe that Math is a great name 
for a project that contains math subcomponents, rather than wading through a 
bunch of different Commons projects. Eventually you are going to want Commons 
Statistics, Commons Transforms, Commons Primes, etc. or things that are even 
more specific. All of these should be modules under Math. To be honest, I’m 
really not clear why Commons Numbers was approved as I’ve never heard anyone 
talk about complex numbers or fractions in anything but a mathematical concept.

I get that what you are really trying to do is kill Commons Math off piece by 
piece. I just don’t agree with doing that.

Ralph



-
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][Math] New component: "Commons Geometry"?

[Dave Brosius]

+1


On 08/17/2017 11:15 AM, Jörg Schaible wrote:

+1

Looks good to me.

Gilles wrote:


Hello.

[Time for a new episode in our "Ripping CM" series.]

How about creating "Commons Geometry"?

The rationale is comprised of the usual suspects:
   * Smaller and more focused component, hence:
 - Consistent development and maintenance.
 - Consistent release schedule, not encumbered by
   changes (and endless discussions) in _totally_
   unrelated code.
 - Potential for attracting contributors not
   interested in maintaining the (growing) backlog
   of CM.
   * Self-contained: 96.3% of the "o.a.c.math4.geometry"
 package have no dependency except:
 - 4 classes now in "Commons Numbers".
 - 2 methods and 1 constant in "MathUtils".
 - CM exceptions. [Creating alternatives for those
   will probably be the most time-consuming part of
   the porting work.]

Moreover, none of the code in the "o.a.c.math4.geometry"
package is used by another package of CM.

A new component would give the "geometry" codes a much
better chance of being (confidently[1]) released, since
CM is "stuck" for the foreseeable future.[2]

WDYT?

Gilles

[1] There seems to be only one issue reported in JIRA
  that pertains to "geometry".
[2] 54 issues yet to be fixed before the 4.0 release;
  which, at the current rate, would lead to after 2025
  (a very rough guess, I admit).



-
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: Modern dependencies among commons

[Dave Brosius]

I have pushed a first patch to move in this direction with commons-beanutils

https://issues.apache.org/jira/browse/BEANUTILS-500


It is breaking in a couple deprecated methods, thus, targetted at a 2.0. 
given that, there are probably other things we'd want to do.



On 07/27/2017 09:48 AM, Jochen Wiedmann wrote:

On Thu, Jul 27, 2017 at 1:52 PM, Jörg Schaible
 wrote:

Claude Warren wrote:


Perhaps change dependency so that it specifies minimum but leaves maximum
open. (unless there is an upper limit)

commons-lang and commons-lang3 are no replacements, they are different
artifacts. Switching from old to new requires changes in code.


I understand the proposal is about making these required changes
*now*. And I am +1 about that.

Jochen





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

Re: [collections][proposal] Java 7

[Dave Brosius]

+1


On 07/25/2017 06:18 PM, Gary Gregory wrote:

Hi All:

I propose we make Java 7 the minimum for Commons Collection 4.2.

Gary




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

Modern dependencies among commons

[Dave Brosius]

Hi Folks,


I'd like to see all of our common components uptake the 'latest' 
versions of other commons components, to encourage their adoption. For 
instance, commons-beanutils still uses commons-collections 3, and so 
when i want to use commons-collections4 myself, i now have to have both 
in the classpath. While there are no conflicts, it's just messy. People 
auto-import the wrong version of collections classes into our code base, 
for instance. If we could get updates to at least the right (major) 
version of jars that would be great.



--dave


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

Re: [collections][proposal] Java 7

[Dave Brosius]

+1


On 07/25/2017 06:18 PM, Gary Gregory wrote:

Hi All:

I propose we make Java 7 the minimum for Commons Collection 4.2.

Gary




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

Re: [LANG] Thoughts about Lang 4.0

[Dave Brosius]

Your point about BiFunction and BiPredicate is of course valid, but 
there are a couple of things about those things that remediate their 
awfulness.



1) They are interfaces, and thus describe function, not storage.

2) They are almost always transiently used, as anonymous/lamda classes, 
and so the scope of their use is small.



On the other hand, Pair is a storage mechanism, and so it is quite 
likely that you encourage developers to build things like MapPair> or such, that live long times and have large 
scopes. That is heinous.



Anyhow, i suppose it's really a tangential topic to this thread, so i 
suppose i hijacked it somewhat, and so apologies... carry on.




On 05/24/2017 11:49 AM, Matt Benson wrote:

On May 24, 2017 9:42 AM, "Rob Tompkins"  wrote:



On May 24, 2017, at 10:33 AM, Dave Brosius  wrote:

Let's be honest, a Pair class is a bad paradigm, invented for lazyness

which throws away any informative metadata. I'm not sure all of this
fighting is worth it over a this.

Dependency/classpath discussions aside (clearly using “Pair” as an example
for the sake of discussion), I agree with Dave here on the strangeness of
the concept of a Pair or Tuple:

It seems that what we’re taking about is an arbitrarily large, yet finite,
collection of one type, and there a substantial number of different ways to
represent this.


Just for the sake of completeness and correctness, the Pair class has
separate type parameters for each item. As to the charge that it is lazy:
sure, but by the same token, so could BiFunction or BiPredicate be
considered lazy, yet they exist in the JDK. Sometimes you just want to get
it done without over-modeling everything, especially if they're used for
implementation rather than as a public API.

Which brings up a fair point: generally speaking it's probably not a good
idea for an API to be defined in terms of some other API, but if a consumer
of [lang] chooses to do that, then they have to deal with the consequences
of compatibility.

Matt


-Rob



On 05/24/2017 09:08 AM, Emmanuel Bourg wrote:

Le 24/05/2017 à 13:55, Stephen Colebourne a écrit :


Library A that depends on lang3 returns a Pair.
Library B that depends on lang4 takes a Pair.
Application cannot pass Pair from A to the B without conversion.

That's a valid point, but the severity depends on the library. joda-time
with its date related types is more data centric than lang and its
static utility classes. The risk of incompatible data structures is
lower with lang, but the risk of an unsolvable binary incompatibility is
higher due to its ubiquity. The strategy adopted to mitigate the
compatibility issues really depends on the usage of the library.

Emmanuel Bourg


-
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: [LANG] Thoughts about Lang 4.0

[Dave Brosius]

Let's be honest, a Pair class is a bad paradigm, invented for lazyness 
which throws away any informative metadata. I'm not sure all of this 
fighting is worth it over a this.



On 05/24/2017 09:08 AM, Emmanuel Bourg wrote:

Le 24/05/2017 à 13:55, Stephen Colebourne a écrit :


Library A that depends on lang3 returns a Pair.
Library B that depends on lang4 takes a Pair.
Application cannot pass Pair from A to the B without conversion.

That's a valid point, but the severity depends on the library. joda-time
with its date related types is more data centric than lang and its
static utility classes. The risk of incompatible data structures is
lower with lang, but the risk of an unsolvable binary incompatibility is
higher due to its ubiquity. The strategy adopted to mitigate the
compatibility issues really depends on the usage of the library.

Emmanuel Bourg


-
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][LAZY] Move commons-imaging to git

[Dave Brosius]

+1


On 05/19/2017 10:03 AM, Amey Jadiye wrote:

+1

On May 18, 2017 10:52 PM, "Rob Tompkins"  wrote:


Hello all,

I would like to propose that we move commons-imaging to git in hopes of
doing that before the potential of releasing a 1.0. I figure that it would
be an easier migration with only a trunk to manage in getting it over there.

For this reason I’m calling a vote by lazy consensus for moving Apache
Commons Imaging to the git version control system. This vote will pass if
nobody objects within the next 72 hours, i.e. after May 21, 2017 1800 (UTC).

Cheers,
-Rob



-
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: [bcel] Any reviewer for my BCEL-289 pull request?

[Dave Brosius]

+1


On 05/18/2017 05:57 AM, Bruno P. Kinoshita wrote:

Hi all,

Found a solution for BCEL-289 [1], and submitted as a pull request [2], but not 
really sure if the old behaviour was intentional for any reason, or just really 
a bug. Never used BCEL, nor read much of its code base before. So happy to have 
someone else reviewing it if possible before it is merged, please (-:

Cheers
Bruno

[1] https://issues.apache.org/jira/browse/BCEL-289
[2] https://github.com/apache/commons-bcel/pull/13

-
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: [DISCUSS] Scala at Commons

[Dave Brosius]

+1 to adding scala (or other) language support.


I'd just rather stay away from mixing languages in projects.


On 02/12/2017 03:36 PM, Oliver Heger wrote:

As we already host some C-code in Commons, I see no reason to reject
Scala or other JVM languages.

I have done some experiments with Scala myself and am very impressed by
this language. I might even have a small library which could become a
component.

One question: Which build tool would we use? I used to have some trouble
with Maven and IDE integration (but this was some time ago); with sbt I
have better experience, but this tool is complex and I don't know how it
can be used for site generation.

Oliver

Am 12.02.2017 um 16:52 schrieb Benedikt Ritter:

Hello,

Commons mission has always been to provide a home for common _Java_ libraries. 
Since my personal and professional interests are slowly shifting from Java 
towards Scala, I’m looking for ways to contribute to Open Source with Scala. 
For this reason I’d like to discuss whether Commons could be a home for common 
Scala libraries as well. For example I’m thinking about wrapper libraries which 
add Scala sugar to the existing libraries. Furthermore there are some Scala 
projects out there at the ASF (Kafka, Spark) which my be interested in sharing 
code via Commons.

Regards,
Benedikt


-
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] Promote TEXT to Proper

[Dave Brosius]

+1


On 01/03/2017 02:39 PM, Rob Tompkins wrote:

Hello all,

I propose that we move [text] to Commons Proper.

--
[ ] +1 Move [text] to Commons Proper
[ ] +0 I am fine with this move
[ ] -0 I am not too keen, because ...
[ ] -1 I am against this move, because ...
--

This VOTE will remain open for a minimum of 72 hours.

Why this proposal? My points follow:

* [text] currently is the most active of the sandbox components.

* Since June of 2016, we have seen nine distinct authors of commits to the 
repository.

* In my opinion, a [text] release will help to accommodate [lang] to become a 
lighter more java language based component by removing a considerable amount 
of, from the perspective of the arbitrary java application developer, 
potentially rarely used text processing algorithms.

Cheers,
-Rob
-
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: Help required for how to unsubscribe

[Dave Brosius]

send an email to


dev-unsubscr...@commons.apache.org 




On 11/17/2016 11:06 PM, venkatesha murthy wrote:

Please help.

thanks
venkat.

Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers

[Dave Brosius]

The problem is the admin/owner has left and refuses to give access to 
anyone else. The team has already decided to hard - fork, and is working 
to get set up. Anyone interested in joining is welcome.


Contact me if interested.


On 11/06/2016 12:32 PM, Stian Soiland-Reyes wrote:

See
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html

In particular the author is not happy about the BCEL integration:


The other major reasons for the FindBugs current bad state:

1) The code is very complex, has "organically grown" over a decade, is
not documented and has poor public interfaces. Most of the code consists
of the very low level bytecode related stuff, tightly coupled with the
ancient BCEL library, which doesn't scale and is not multi-thread safe.
No one enjoys maintaining this code, at least not me. I see no future
for FindBugs with the BCEL approach, and see no way to get rid of it
without investing lot of effort, and without breaking every detector and
possibly many 3rd party tools. This is the biggest issue we have with
FindBugs today, and most likely the root cause for all the evil. This
code can't be fixed, it must be rewritten.

..but the main problem seems to be lack of maintaners.





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

Re: [lang] To Java 7

[Dave Brosius]

Of course not. people with ancient builds never touch anything.


On 10/23/2016 09:49 PM, Matt Sicker wrote:

Do you really think the users who are paying for extended Java 6 support
are upgrading any of their dependencies anymore?

On 23 October 2016 at 20:42, sebb  wrote:


It seems that Java 6 is still supported until Dec 2018 if the user
purchases Extended Support.

There are users who cannot or will not upgrade until then [1]

[1] https://lists.apache.org/thread.html/6ad212d930574a4fc3c149242561fb
7228b272d9b80a4daaeee4326f@%3Cuser.commons.apache.org%3E

On 23 October 2016 at 14:59, Matt Sicker  wrote:

+1, maybe there are some new features that can be added that are relevant
to JDK 7 besides just language level cleanups.

On 23 October 2016 at 07:07, Dave Brosius  wrote:


+1


On 10/23/2016 03:30 AM, Gary Gregory wrote:


Hi All:

Now that 3.5 is out, I think it is time to require Java 7.

Thoughts?

Gary



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




--
Matt Sicker 

-
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: [lang] To Java 7

[Dave Brosius]

+1


On 10/23/2016 03:30 AM, Gary Gregory wrote:

Hi All:

Now that 3.5 is out, I think it is time to require Java 7.

Thoughts?

Gary




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

Re: [ALL] Get things moving with "random utilities"

[Dave Brosius]

+1
---


On 2016-10-19 13:43, Jörg Schaible wrote:

Hi,

Gary Gregory wrote:

To restate my opinion and that of others: It is not a good thing to 
end up
with components Commons Random A, Commons Random B, Commons Random C, 
and
so on. We already have a new Commons Random Something component. 
Related

code should be modules of that component.


let's see it from the practical side. Commons RNG is supposed to stay 
stable

as long as possible. Commons RNG Tools might have a much faster turn to
break APIs. If you put both together, you'll have either to manage the
submodules like individual components with own GAV (and where's the 
benefit
then apart from our unprepared tooling of such an scenario?) or you 
have to
change the package name of Commons RNG quite more often then necessary, 
just
because you restructure something in the RNG tools that is 
incaompatible

(not very good for users of RNG).

Therefore I'm with Gilles here and would simply say: Let's try it with 
two
independent components and time will tell if it was a good choice or 
not.


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: [RNG] Release of v1.0: Schedule update

[Dave Brosius]

i think people understand an early product having breaking changes. The 
interface is 'small' enough that having to redo a small amount of change 
by clients is not an issue here. Whatever you do, it's likely that you 
will get feedback from clients that you don't expect, which probably 
prompts you to want breaking changes anyway. I'd just release it, and 
get some momentum going.



dave


On 10/06/2016 01:36 PM, Gary Gregory wrote:

On Thu, Oct 6, 2016 at 10:07 AM, Dave Brosius  wrote:


I'd vote for putting down the paint brushes temporarily and consider the
bike shed done.

Let's get 1.0 out, and then folks can work on 1.1 while getting feedback
from users, etc.


But is the painting considered for 1.1 in risk of breaking BC? If yes, we
need to keep talking or accept that the next release would be a BC-breaking
2.0. Both are fine with me, we just need to agree on a road-map.

Gary


--dave

---





On 2016-10-06 11:10, Gilles wrote:


On Wed, 5 Oct 2016 18:04:43 +0200, Emmanuel Bourg wrote:


Le 5/10/2016 à 18:01, Gilles a écrit :

There hasn't been any repository activity concerned

with the above reports or other such new features.

Were there unanticipated problems?


Just lengthy (and not yet finished) discussions :)


Well, you started them.

And they were on issues[1] supposed to be left for after
1.0; and the LCG could have been added to a 1.1 release
(had I known that those discussions would pop up).

I'm still working on

the LCG.


OK, but I'd like to know where we stand in terms of schedule
(given that, with a very comfortable margin for review, the
intended functionality[2] could have been released at least
3 weeks ago[3], if not much earlier[4]).

Hence, could you please be more specific?
 From the above I could only infer that it could take at leat
another week (to run the stress tests and update the user
guide).


=
Warning: rant follows; those who are not willing to help
clear the atmosphere of the Commons project[5] are welcome
to stop reading at this point. :-)
=

Since, on the PMC-private list, I've been accused of personal
attack (which I deny[6] because the incriminated passages were
in fact a reminder that one could not actually search for
"consensus"[7][8] when not taking the other's POV into account),
I'm obliged to stress that silently breaking an agreement is
something which one can rightfully consider as an attack.

=
Defusing statements follow (which you should be read before
dismissing the above as an overly sensitive reaction).
=

I assume that the attack was not intentional; we work on a
best-effort basis.
However, because we are _all_ working on a best-effort basis,
"agreement" must mean something.
Too often, what seemed to be an agreement turned out to be
more akin to a decoy[9]; this is _my_ feeling, thus not an
attack on anyone!

Do I need to stress that such a feeling is not nice,
especially in a place where "community" spirit is so
touted?[10]

When everything goes smoothly and everybody is of the same
opinion, then it is easy to go by the "community over code"
mantra.  You obviously don't even need it.
When there is divergence, it takes a lot more than saying
the "c7s" word for it to transform into reality.[11]

I'd suggest that people make some introspection into what
"community over code" could mean so that it actually helps,
rather than hinders, cooperation.[12]  The obvious sense which
one could infer from the phrase may indeed not be the most
effective towards that (IMO) worthy goal.

Thanks for your attention,
Gilles

[1] Largely stemming from your misunderstanding of the intended
 scope of "Commons RNG".
[2] Which I assumed was trivially inferred from the decisions
 taken within Commons Math (namely "pure Java" and the like).
[3] http://markmail.org/message/ymt43f3ajqm25vkk
[4] A big part of that code has actually been available for
 review since last March (albeit within development branches
 of Commons Math), and the issues being dealt with takes back
 to December 2015 (more than 9 months ago).
[5] A state of affairs that has made people leave, whatever the
 (real or perceived) reason.
[6] The ML archive is rather full of attacks against me (having
 been depicted as dismissive, stubborn, a sloppy coder, down
 to plainly stupid).
[7] Only Stian made some constructive step by spelling out the
 pros and cons of "modules vs projects".
 Yet nobody else seems interested to take that as input and
 consider the _realistic_ scope of "Commons RNG" in order to
 reach a conclusion.
[8] More on this in that other thread...
[9] With the consequence that I had been lured in doing actual,
 often tedious, work (for the sake of consensus) even when I
 had deemed it useless; and turned out to be so, in many cases.
 You can 

Re: [RNG] Release of v1.0: Schedule update

[Dave Brosius]

I'd vote for putting down the paint brushes temporarily and consider the 
bike shed done.


Let's get 1.0 out, and then folks can work on 1.1 while getting feedback 
from users, etc.


--dave

---




On 2016-10-06 11:10, Gilles wrote:

On Wed, 5 Oct 2016 18:04:43 +0200, Emmanuel Bourg wrote:

Le 5/10/2016 à 18:01, Gilles a écrit :


There hasn't been any repository activity concerned
with the above reports or other such new features.

Were there unanticipated problems?


Just lengthy (and not yet finished) discussions :)


Well, you started them.

And they were on issues[1] supposed to be left for after
1.0; and the LCG could have been added to a 1.1 release
(had I known that those discussions would pop up).


I'm still working on
the LCG.


OK, but I'd like to know where we stand in terms of schedule
(given that, with a very comfortable margin for review, the
intended functionality[2] could have been released at least
3 weeks ago[3], if not much earlier[4]).

Hence, could you please be more specific?
From the above I could only infer that it could take at leat
another week (to run the stress tests and update the user
guide).


=
Warning: rant follows; those who are not willing to help
clear the atmosphere of the Commons project[5] are welcome
to stop reading at this point. :-)
=

Since, on the PMC-private list, I've been accused of personal
attack (which I deny[6] because the incriminated passages were
in fact a reminder that one could not actually search for
"consensus"[7][8] when not taking the other's POV into account),
I'm obliged to stress that silently breaking an agreement is
something which one can rightfully consider as an attack.

=
Defusing statements follow (which you should be read before
dismissing the above as an overly sensitive reaction).
=

I assume that the attack was not intentional; we work on a
best-effort basis.
However, because we are _all_ working on a best-effort basis,
"agreement" must mean something.
Too often, what seemed to be an agreement turned out to be
more akin to a decoy[9]; this is _my_ feeling, thus not an
attack on anyone!

Do I need to stress that such a feeling is not nice,
especially in a place where "community" spirit is so
touted?[10]

When everything goes smoothly and everybody is of the same
opinion, then it is easy to go by the "community over code"
mantra.  You obviously don't even need it.
When there is divergence, it takes a lot more than saying
the "c7s" word for it to transform into reality.[11]

I'd suggest that people make some introspection into what
"community over code" could mean so that it actually helps,
rather than hinders, cooperation.[12]  The obvious sense which
one could infer from the phrase may indeed not be the most
effective towards that (IMO) worthy goal.

Thanks for your attention,
Gilles

[1] Largely stemming from your misunderstanding of the intended
scope of "Commons RNG".
[2] Which I assumed was trivially inferred from the decisions
taken within Commons Math (namely "pure Java" and the like).
[3] http://markmail.org/message/ymt43f3ajqm25vkk
[4] A big part of that code has actually been available for
review since last March (albeit within development branches
of Commons Math), and the issues being dealt with takes back
to December 2015 (more than 9 months ago).
[5] A state of affairs that has made people leave, whatever the
(real or perceived) reason.
[6] The ML archive is rather full of attacks against me (having
been depicted as dismissive, stubborn, a sloppy coder, down
to plainly stupid).
[7] Only Stian made some constructive step by spelling out the
pros and cons of "modules vs projects".
Yet nobody else seems interested to take that as input and
consider the _realistic_ scope of "Commons RNG" in order to
reach a conclusion.
[8] More on this in that other thread...
[9] With the consequence that I had been lured in doing actual,
often tedious, work (for the sake of consensus) even when I
had deemed it useless; and turned out to be so, in many cases.
You can thus guess that, over the years, I was less and less
amenable to accept such "consensus" (whenever one-sided
"bargain" would have been a more appropriate description).
[10] Nobody finds it surprising that, in foreign policy, such a
 behaviour can lead to war; so why would it be surprising
 that it can poison the atmosphere in other areas too?
[11] It takes at least figuring out why some code is as it is;
 some "code archeology" would have provided many answers
 without the need to bring, again, the issues to the ML.
[12] Cooperation is certainly not letting someone work for 9
 months, not answering any of his requests for comments, and
 after all the code has been designed alone, and shown to be
 consistent, robust and correct (through almost 100% coverage,
 consolidation of the existing unit tests, and passing the
 most stringent test suites), start critic

Re: [VOTE][RC2] Release "Apache Commons RNG" version 1.0

[Dave Brosius]

Let's release RNG 1.0. If our customers see areas of improvements with 
regard to modularization, i'm sure they will let us know. But it seems 
to me this code base is fine for a 1.0 release. Release early and often.


--dave


On 09/18/2016 12:24 PM, Emmanuel Bourg wrote:

Le 18/09/2016 à 13:57, Gilles a écrit :

I can't help it!
I'll comment...

On Sat, 17 Sep 2016 17:28:19 +0200, Emmanuel Bourg wrote:

Try me.  Really.
What is your plan toward modularization?

I've exposed mine, let's see yours.

I can't help it either, I'm a nice guy. I have no strong opinion on the
modularization of RNG. Intuitively, considering the size of the original
code coming from the random package in Commons Math I feel that a
separate module is probably not necessary. But I haven't examined your
proposal thoroughly yet.

Emmanuel Bourg


-
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][RC2] Release "Apache Commons RNG" version 1.0

[Dave Brosius]

+1


On 09/16/2016 05:46 PM, Gilles wrote:

Hi.

This is a [VOTE] for releasing Apache Commons RNG 1.0 (from RC2).

Tag name:
  RNG_1_0_RC2 (signature can be checked from git using 'git tag -v')

Tag URL:
https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=commit;h=412ffb37932c45d7664eb83bd540f81d27a02b84

Commit ID the tag points at:
  412ffb37932c45d7664eb83bd540f81d27a02b84

Site:
  http://home.apache.org/~erans/commons-rng-1.0-RC2-site

Distribution files:
  https://dist.apache.org/repos/dist/dev/commons/rng/

Distribution files hashes (SHA1):
   eb947802b687835983803147cfc0e51be97ae521 
commons-rng-1.0-bin.tar.gz.sha1

   200840fb29abd126ce9b046549cff04fda4f151a commons-rng-1.0-bin.zip.sha1
   b872f12f68de7d9f929299badf0d0ddcc835bbf3 
commons-rng-1.0-src.tar.gz.sha1

   31e6d6a5973b37904e2646675bd0c9beaa6c301f commons-rng-1.0-src.zip.sha1

KEYS file to check signatures:
  http://www.apache.org/dist/commons/KEYS

Maven artifacts:
https://repository.apache.org/content/repositories/orgapachecommons-1201/org/apache/commons/commons-rng/1.0/

[ ] +1 Release it.
[ ] +0 Go ahead; I don't care.
[ ] -0 There are a few minor glitches: ...
[ ] -1 No, do not release it because ...

This vote will close in 72 hours, at 2016-09-20T00:00:00Z (this is UTC
time).
--

Thanks,
Gilles


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





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

Re: [rng] Cleanup of "topic" branches

[Dave Brosius]

i'm not sure what the value of dead branch labels hanging around is. 
They just clutter things up and confuse new people coming it as to what 
to use. I'm +1 for deleting them.





On 09/11/2016 02:26 PM, Jochen Wiedmann wrote:

On Sun, Sep 11, 2016 at 5:32 PM, Gary Gregory  wrote:

Once a branch has been merged into master, I think it is OK to remove it.
Otherwise, IMO it's on a case by case basis: Does the author of the branch
need it?

Whats the point? I'd rather see us create something like
branches/archived and move such branches below.

Basically same effect, but provides accessibility.

Jochen





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

Re: Unsubscribe me

[Dave Brosius]

Hi Carrie,


If you'd like to unsubscribe send an email to

dev-unsubscr...@commons.apache.org


On 09/06/2016 07:14 AM, carrie.ctr.w...@faa.gov wrote:


-Original Message-
From: brit...@apache.org [mailto:brit...@apache.org]
Sent: Saturday, September 03, 2016 1:18 PM
To: comm...@commons.apache.org
Subject: svn commit: r1759120 - /commons/proper/io/IoNowUsesGit.txt

Author: britter
Date: Sat Sep  3 18:17:48 2016
New Revision: 1759120

URL: http://svn.apache.org/viewvc?rev=1759120&view=rev
Log:
Add readme for SVN archive to old IO svn repository location

Added:
 commons/proper/io/IoNowUsesGit.txt   (with props)

Added: commons/proper/io/IoNowUsesGit.txt
URL: 
http://svn.apache.org/viewvc/commons/proper/io/IoNowUsesGit.txt?rev=1759120&view=auto
==
--- commons/proper/io/IoNowUsesGit.txt (added)
+++ commons/proper/io/IoNowUsesGit.txt Sat Sep  3 18:17:48 2016
@@ -0,0 +1,9 @@
+The Commons IO project now uses Git for its source code respository.
+
+
+Please see:
+
+http://commons.apache.org/io/source-repository.html
+
+The SVN tree has been moved to:
+https://svn.apache.org/repos/asf/commons/_moved_to_git/io

Propchange: commons/proper/io/IoNowUsesGit.txt
--
 svn:eol-style = native



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



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

Re: [Math] Getting things done

[Dave Brosius]

I realize there are good intentions here. But what the common theme of 
all these email chains, when you filter out the disagreements, is, 
"deferred until"


If 'deferring' is the only thing we can agree on, i think something is 
broken with the system.


IMO let the doers do. Clearly Gilles is the main driver of change. It 
appears he now has some people who will help at least to some extent, 
but he has shown over last half year (at least) that he will be the 
primary one to move the code base.


I would just have Gilles (and friends) go ahead and make the changes he 
feels are the right direction. If he were to take an inordinate dump in 
the code base (he won't), or walk away with it half-baked (he won't), 
the next person along, if ever, just can go back to an earlier branch 
point and start again.


But we are supposed to be a meritocracy, not an oligarchy. It feels much 
like that later at the moment.


dave

On 06/23/2016 08:53 AM, Ralph Goers wrote:

My answer would be slightly different.  It doesn’t. All topics related to the 
code should be deferred until we know what is happening with the community.

Ralph


On Jun 23, 2016, at 5:50 AM, Jochen Wiedmann  wrote:

It doesn't, at least in my opinion. If the future Math project decides
to have a "base" component: Very well. But, if the other components
are elsewhere: Why should the base stay at Commons?


On Thu, Jun 23, 2016 at 2:48 PM, Eric Barnhill  wrote:

There has been a lot of support in the discussions for, as Emmanuel put it,
a "base commons-math
component".

Where does that factor into this proposal?

On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann 
wrote:


Hi,

I'd like an attempt to put an end to all those discussions regarding
Commons Math (CM). That means, in particular, that we find an common
agreement on a course of action. So, here's a suggestion (might as
well call it an offer, because acceptance would mean a lot of work on
my side)

  1.) I'll write a proposal to move CM to the Incubator.
  2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
  3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
  4.) If the board accepts the TLP: Very well.
  5.) If not: So what. Now we know, at least.

In either case: At the end of the procedure, we'd have clarity. This
will allow us to focus on a smaller set of issues (technical), and we
can go on.

The important part, to me, is to find something on which we can agree.
That doesn't mean that everyone is happy with the outcome, but that
everyone's got the feeling "I can live with that". In particular,
there must not be any serious opposition later on. If you'd like to
oppose: Please do so here, and now.

Thanks,

Jochen



--
The next time you hear: "Don't reinvent the wheel!"


http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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





--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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





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





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

Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC6

[Dave Brosius]

Doubt it, but you could certainly 'shade 
' the plugin with 
maven to convert all references from the original path to the path 
you're expecting.


On 06/20/2016 07:14 PM, Mark Roberts wrote:

Sorry - I'm replying to my own post.  Is there any chance that there is a 
revision point in the active tree that corresponds exactly to RC6 but without 
the path changes?  I could do some testing on that.

Probably too much to hope for.

Thanks,
Mark


-Original Message-
From: Mark Roberts [mailto:mar...@cs.washington.edu]
Sent: Monday, June 20, 2016 4:12 PM
To: 'Commons Developers List'
Cc: 'findbugs-disc...@cs.umd.edu'; 'findbugs-c...@lists.sourceforge.net'
Subject: RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC6

Well I was clearly confused about this release.  It has reverted back to the old
class hierarchy in the name of binary compatibility.  I can see now that that
was the intention and it makes sense.  However, I cannot test it (and hence
vote up or down) as I am certainly not going to edit all my sources back to the
'old' system.

So my question is what is the plan?  This release gets me no closer to a place
where I can quit providing my own version of BCEL with our Daikon product.
What is the plan for a release from the active tree with the new class
hierarchy?

Thank you,
Mark Roberts



-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org]
Sent: Monday, June 20, 2016 12:37 PM
To: Commons Developers List
Cc: findbugs-disc...@cs.umd.edu; findbugs-c...@lists.sourceforge.net
Subject: [VOTE] Release Apache Commons BCEL 6.0 based on RC6

Hi,

after some build related problems with RC5, I'd like to call a vote to
release Apache Commons BCEL 6.0 based on RC6. The only changes
compared to
RC5 is a fix in the source assembly: It now includes all files
necessary to run a clean build.

BCEL 6.0 RC6 is available for review here:
   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14065)

The tag is here:



https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_R

C6
  (rev 1749388)

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-
1179/org/apache/bcel/bcel/6.0/

These are the Maven artifacts and their hashes:

bcel-6.0-javadoc.jar
(SHA1: 89cf95656f0f8a93e77100c8d5811f7cd9af866b)
bcel-6.0-sources.jar
(SHA1: 162f96530e8935e8a71a9e6d5497026aa3bdc945)
bcel-6.0-test-sources.jar
(SHA1: 2b07be3a0a4560c9766d3261cd012cf636fe965a)
bcel-6.0-tests.jar
(SHA1: 9e825da46e0cd66f87ccd907a43c4e2ebd15b8d6)
bcel-6.0.jar
(SHA1: 09d0a4c32ba6c3c22f0680f89ceeaf3e677ac659)
bcel-6.0.pom
(SHA1: a5d48ac34909f3a0ac788d37835075be5c2bb9d7)

I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS 10.11.5.

Details of changes since 5.2 are in the release notes:
   https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-

NOTES.txt

   http://home.apache.org/~britter/commons/bcel/6.0-RC6/changes-
report.html

Site:
   http://home.apache.org/~britter/commons/bcel/6.0-RC6/
(note some *relative* links are broken and the 6.0 directories are not
yet created - these will be OK once the site is deployed)

Clirr Report (compared to 5.2):

http://home.apache.org/~britter/commons/bcel/6.0-RC6/clirr-report.html

Note that Clirr reports several errors. These have been discussed on
the ML already and I uploaded the site a while ago giving everybody
the opportunity to raise objections against these changes. These
changes are also explicitly noted in the Release notes.

Furthermore java.io.Serializable has been dropped from all BCEL
classes. An extended Clirr report including this change can be reviewed

here:

http://home.apache.org/~britter/commons/bcel/6.0-RC6/bcel5-bcel6-clirr
-
report.html

We don't consider this to be a problem because we don't see a reason
for users to serialize BCEL classes.

RAT Report:

http://home.apache.org/~britter/commons/bcel/6.0-RC6/rat-report.html

KEYS:
   https://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. sometime
after
22:00 CEST 23-June 2016

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

We're almost there... :-)
Thanks!
Benedikt


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

Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC5

[Dave Brosius]

+1


Am 18.06.2016 um 16:54 schrieb Benedikt Ritter:

Hi,

more then 10 years have passed since we've released BCEL 5.2. Users are
waiting for us to release a new version capable of handling Java 6, 7 and 8
byte code. There have already been 4 release candidates for BCEL 6.0 but
they have not made it for various reasons. Most importantly BC has been
broken. Package and Maven coordinates have been changed according to our
release guidelines. However our users have asked us to provide a binary
compatible release and here we are...

I'd like to call a vote for releasing Apache Commons BCEL 6.0 based on RC5.

BCEL 6.0 RC1 is available for review here:
   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14039)

The tag is here:
   https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC5 (rev
1749058)

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1177/org/apache/bcel/bcel/6.0/

These are the Maven artifacts and their hashes:

bcel-6.0-javadoc.jar
(SHA1: 79b5fd315f5f949580268e55c0baa85e18df4740)
bcel-6.0-sources.jar
(SHA1: f4ab6e682465471084e601c49e03a1385c610343)
bcel-6.0-test-sources.jar
(SHA1: 9aabf73fd9680336000f54a29fc234eaf474fc85)
bcel-6.0-tests.jar
(SHA1: f34db9121dd7b2dd198754416d29258a96549789)
bcel-6.0.jar
(SHA1: e6546a05530e8ed64b07cb917a8dca7912a16404)
bcel-6.0.pom
(SHA1: 76c9509859b13c74ff082e489b247708c48e59cb)

I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS 10.11.5.

Details of changes since 5.2 are in the release notes:
   https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
   http://home.apache.org/~britter/commons/bcel/6.0-RC5/changes-report.html

Site:
   http://home.apache.org/~britter/commons/bcel/6.0-RC5/
(note some *relative* links are broken and the 6.0 directories are not yet
created - these will be OK once the site is deployed)

Clirr Report (compared to 5.2):
   http://home.apache.org/~britter/commons/bcel/6.0-RC5/clirr-report.html

Note that Clirr reports several errors. These have been discussed on the ML
already and I uploaded the site a while ago giving everybody the
opportunity to raise objections against these changes. These changes are
also explicitly noted in the Release notes.

Furthermore java.io.Serializable has been dropped from all BCEL classes. An
extended Clirr report including this change can be reviewed here:

http://home.apache.org/~britter/commons/bcel/6.0-RC5/bcel5-bcel6-clirr-report.html

We don't consider this to be a problem because we don't see a reason for
users to serialize BCEL classes.

RAT Report:
 http://home.apache.org/~britter/commons/bcel/6.0-RC5/rat-report.html

KEYS:
   https://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. sometime after 17:00 CEST 21-June 2016

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

Thanks!
Benedikt


-
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: [BCEL] 5.3 is going to be messy

[Dave Brosius]

On 06/07/2016 06:39 AM, sebb wrote:

On 7 June 2016 at 11:15, Torsten Curdt  wrote:

1) I don't believe we should force users to migrate their code in
order to support java 7/8.


...and that line of thinking is why it feels like commons projects are
effectively stuck in the past.

And maybe the ease of upgrade is why they are popular with users.


What upgrade? When have the users had to upgrade? like 3 years ago?



No one needs to upgrade. If your projects live in the past - there are bug
fix releases.

That's not the case in general. Very few commons projects maintain
parallel releases.


But if you want the new shiny then you as well should be OK to put in some
effort to do so.

Why should the user have to do so?


There's one thing above all else that really is painful to the user. No 
upgrades!

Why are there no upgrades? Because there are no developers!
Why are there no developers? Because they are punished with a horrendous
development experience. Oh boy, can't wait to develop with 1.5 in SVN!! 
that's a treat.





Change should be easy - not just for our user but also for us.

There are many more users than there are developers.


My 2 cents

Suppose there are 10 developers on BCEL; that's 20 cents.

There may be 1000 or more users.

That's 20 dollars.

-
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: [bcel] Deprecated InstructionConstants

[Dave Brosius]

Commons should be happy to ignore compatibility, update to 1.8, change 
package and maven coordinates, change interfaces to take advantage of 
generics, become a modern code base. Staying in the 1.5 world, BCEL, 
which is already dying, will die. No competent developer coming in from 
the outside will look at BCEL and say, now _that_ is something i want to 
work on.


This was the plan all along, and then someone came along and said, why 
are we breaking backwards compatibility, and undid everything.


This is a major version, can we please move forward.



On 06/02/2016 06:07 AM, sebb wrote:

No, it's a consequence of the way the Java classpath and Maven work.

If Commons wishes to release a compatible version of BCEL, it must use
the same Java package and Maven coordinates.
(as well as ensure that any changes to the public API are at least
binary-compatible)

If Commons is happy to ignore compatibility, it can release a new
version with different package and Maven coordinates.
However this means downstream users have to update and recompile their source.



On 2 June 2016 at 10:41, dbrosIus  wrote:

This is the problem with Commons.

 Original message 
From: sebb 
Date: 06/02/2016  5:15 AM  (GMT-05:00)
To: Commons Developers List 
Subject: Re: [bcel] Deprecated InstructionConstants

On 2 June 2016 at 07:56, Benedikt Ritter  wrote:

Gary Gregory  schrieb am Do., 2. Juni 2016 um
08:00 Uhr:


So trunk packages would be renamed _back_ from bcel6 to the 5.2 packages?


That's what I understood from sebb's last message.

Yes, that would need to happen to support BC.


Gary

On Wed, Jun 1, 2016 at 3:43 PM, sebb  wrote:


Hang on please.

There were plans to produce a new incompatible release with new Maven
coords and new package names.
However as I recall there was some pushback from users who wished to
have a drop-in release.
That is not possible unless the release is binary compatible.

So I spent quite a bit of effort reworking the changes so as to
facilitate a binary compatible release.
As far as I can recall, that effort was successful apart from changes
to an interface (or two).

There were some ideas as to how to resolve the interface
incompatibilty, but no agreement was reached.
I think the options were:
- introduce new interface(s) extending the old one(s)
- keep the interface(s) and handle any runtime errors
- use the Java 8 (?) facility which allows an interface to contain a
method implementation.

Note that the code does not yet support some Java 8 features.


On 1 June 2016 at 09:34, Jan Matèrne (jhm)  wrote:

It does not make sense though. All of the code in the bcel6 package is
going to be released for the first time in the upcoming 6.0 release.

Ok, didnt know that.
Then I'm fine :)

Just wanted to give a hint.


Jan


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


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




--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

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





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

Re: [Math] Change on branch "master": Commons Math MasterBranch - Build # 6 - Successful

[Dave Brosius]

ok, apologies. sorry

On 05/29/2016 05:47 PM, Gilles wrote:

Hi Dave.

Please stop performing changes on the "master" branch!
[See also my other mail.]

Except for trivial modifications (e.g. typo in Javadoc), it was customary
to file a JIRA report to link to the commit.

A bunch of (even fairly trivial) modifications could be the object of
a JIRA report (like "Cleanup in the stat package").


Thanks for your help and understanding,
Gilles

On Sun, 29 May 2016 21:40:27 + (UTC), Apache Jenkins Server wrote:

The Apache Jenkins build system has built Commons Math MasterBranch
(build #6)

Status: Successful

Check console output at
https://builds.apache.org/job/Commons%20Math%20MasterBranch/6/ to view
the results.



-
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: [Poll][VFS] Switch to Git

[Dave Brosius]

+1

On 05/25/2016 04:55 PM, Gary Gregory wrote:

On Wed, May 25, 2016 at 1:20 PM, Bernd Eckenfels 
wrote:


Hello,

I would like to be able to use Git with the Apache Commons VFS repo. As
we agreed upon I call out the intention to do this and ask you for your
oppinion.


+1

Gary



Now that we have the 2.1 release out of the way the switch wont affect
any planned steps.

Anybody opposed to this move? I will probably need a few days to come
back to this, so this poll with lazy consensus is open for at least 5
days.

Gruss
Bernd

-
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: [io] Make requirement Java 7?

[Dave Brosius]

The other side would say we are enabling crap code on unsupported, 
unprotected jvms. New Java 6 development will die (more quickly) when 
big libraries like commons-io stop supporting it. As it is, we are the 
Java 6 drug dealers.


On 04/26/2016 09:28 AM, Emmanuel Bourg wrote:

Le 26/04/2016 14:57, Dave Brosius a écrit :


The extra management that's required is not worth the
2 people who want a new version of commons-io for java 6. We are talking
about an end of life date coming up on 4 years.

There is no extra management besides configuring the Maven compiler
plugin to generate Java 6 bytecode and refraining from using Java 7 APIs
unless absolutely required (and preferably in dedicated classes).

commons-io is our most used component, we have to be conservative as it
impacts many projects.

Emmanuel Bourg


-
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: [io] Make requirement Java 7?

[Dave Brosius]

People stuck on Java 6, for whatever inane reason, are in a very 
restrictive use case, and as such are not likely doing 'progressive' 
things like upgrading 3rdparty jars. I just don't see the point of 
trying to support some of the new release's code base on java 6, and 
others on java 7. The extra management that's required is not worth the 
2 people who want a new version of commons-io for java 6. We are talking 
about an end of life date coming up on 4 years.



Just upgrade the whole thing to 7.

-dave

On 04/26/2016 08:41 AM, Emmanuel Bourg wrote:

Le 26/04/2016 14:29, sebb a écrit :


How can we say that the source code is Java 6 compatible if it cannot
be compiled with Java 6?

It's Java 6 compatible at runtime, not at build time. We can say that
because:
- the project is configured to generate Java 6 compatible bytecode
- 99% of the code doesn't use Java 7 APIs

The Java 6 compatibility stops if the new utils classes are used.



The ASF releases source.

Yes, and we release source that builds with Java 7 and runs with Java 6.

Emmanuel Bourg


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





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

Re: [Math] About MATH-1329

[Dave Brosius]

Git blame says

git blame -L1028 
src/main/java/org/apache/commons/math4/linear/RealVector.java
760078b4 src/main/java/org/apache/commons/math/linear/RealVector.java 
(Gilles Sadowski   2011-08-28 12:58:57 + 1028) protected class 
Entry {


Was like that from the first time it was added.

So i suppose you have yourself to blame ;)

On 02/28/2016 08:10 PM, Gilles wrote:

Hi.

https://issues.apache.org/jira/browse/MATH-1329

Any idea why the "Entry" of a "RealVector" is "protected"?


Regards,
Gilles


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





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

Re: [JXPATH] Java Version

[Dave Brosius]

As has java 7 reached end of life.

On 11/22/2015 09:06 AM, Benedikt Ritter wrote:

I'm fine with Java 7, since Java 6 has already reached EOL.

2015-11-21 19:48 GMT+01:00 Gary Gregory :


I'd go with Java 7.

Gary
On Nov 21, 2015 3:50 AM, "Benedikt Ritter"  wrote:


Hi,

any preference on which Java Version JXPath 1.4 target? Currently the

build

is set to 1.3. I've only Java 1.6, 1.7 1.8 and 1.9 installed on my

machine,

so I won't be able to test with 1.3, 1.4 and 1.5. Further more I don't

see

a reason to keep support for such old Java versions.

Thoughts?
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: [RESULT] [VOTE] Accept Naomi

[Dave Brosius]

Folks,

I take it from our collective lack of movement, that we are voting no, 
and just not willing to say it. If that is the case, we should have the 
courtesy to say no, and at least give closure.


dave

On 11/08/2015 02:14 PM, Dave Brosius wrote:
I have already merged the changes into master, and deleted the 
gh-pages branch here


https://github.com/mebigfatguy/Naomi


I can add a pull request to Norm to accept these in his repository, if 
you like.



On 11/08/2015 01:53 PM, Bernd Eckenfels wrote:

Phil:

I am not happy about proceeding, though, in the presence of the

-1

votes.  We like to make decisions by consensus and while this is a
procedural decision and therefore subject to majority approval, I
would like to ask those who case negative votes to reconsider.

I have an counter proposal: how about addressing most of the concerns
first:

- merge the mavenisation cleanly, it is not asked too much to display
   it in master not gh-pages
- add some samples to the readme
- adopt commons codestyle

If those 3 things are done by the submitters I personally would be very
reliefed (I still would not see a case to use it myself, but at least
we wont have any ground for the rockstar argument anymore). I am not
sure about the "incubator" argument, as I understood it, it is not
needed for IP clearance.

And given the vote already passed you can just make the above clean-up
in git(hub) and get it merged to the sandbox.

gruss
Bernd

-
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: [RESULT] [VOTE] Accept Naomi

[Dave Brosius]

I have already merged the changes into master, and deleted the gh-pages 
branch here


https://github.com/mebigfatguy/Naomi


I can add a pull request to Norm to accept these in his repository, if 
you like.



On 11/08/2015 01:53 PM, Bernd Eckenfels wrote:

Phil:

I am not happy about proceeding, though, in the presence of the

-1

votes.  We like to make decisions by consensus and while this is a
procedural decision and therefore subject to majority approval, I
would like to ask those who case negative votes to reconsider.

I have an counter proposal: how about addressing most of the concerns
first:

- merge the mavenisation cleanly, it is not asked too much to display
   it in master not gh-pages
- add some samples to the readme
- adopt commons codestyle

If those 3 things are done by the submitters I personally would be very
reliefed (I still would not see a case to use it myself, but at least
we wont have any ground for the rockstar argument anymore). I am not
sure about the "incubator" argument, as I understood it, it is not
needed for IP clearance.

And given the vote already passed you can just make the above clean-up
in git(hub) and get it merged to the sandbox.

gruss
Bernd

-
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] Accept Naomi

[Dave Brosius]

Emmanuel,

I understand where your opinions come from, and respect your arguments.
I generally agree with your sentiments, that run of the mill 'github
projects' should not be added to Apache willy-nilly.

I think this contribution however is not the run-of-the-mill type, nor
are the contributors. Both Norm and Jeff are retiring engineers with
long and distinquished careers, having made _significant_ contributions
to computer science. That they would like to contribute something to
Apache, i take as quite an honor, myself. Your concerns over how will a
community be built, and what level of involvement will the original
authors give, is normally quite valid, but in this case, begs for some
exceptions.

This project is really quite promising, in my opinion. That it is a bit
rough around the edges, is valid, but that it is a fluent, ease of use
library over a potentially difficult area is really what Apache tends to
do quite often. Apache as an organization is good at taking good ideas
that perhaps are not in perfect shape, and turning them into
professional libraries. This is something this library would do well for.

I certainly respect your opinion, but would ask that you reconsider, if
possible.

---dave

On 10/30/2015 07:06 AM, Emmanuel Bourg wrote:

Le 30/10/2015 01:42, Phil Steitz a écrit :


[X] -1 We should not do this, because...

Sorry I feel this is going too fast. I don't think Apache Commons should
turn into a forge hosting any small project asking to join. I see more
Apache Commons as a ground for gathering libraries developed in other
Apache projects. I don't think we should turn into a Github alternative
with the Apache brand.

Emmanuel Bourg


-
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] Accept Naomi

[Dave Brosius]

Emmanuel,

I understand where your opinions come from, and respect your arguments. 
I generally agree with your sentiments, that run of the mill 'github 
projects' should not be added to Apache willy-nilly.


I think this contribution however is not the run-of-the-mill type, nor 
are the contributors. Both Norm and Jeff are retiring engineers with 
long and distinquished careers, having made _significant_ contributions 
to computer science. That they would like to contribute something to 
Apache, i take as quite an honor, myself. Your concerns over how will a 
community be built, and what level of involvement will the original 
authors give, is normally quite valid, but in this case, begs for some 
exceptions.


This project is really quite promising, in my opinion. That it is a bit 
rough around the edges, is valid, but that it is a fluent, ease of use 
library over a potentially difficult area is really what Apache tends to 
do quite often. Apache as an organization is good at taking good ideas 
that perhaps are not in perfect shape, and turning them into 
professional libraries. This is something this library would do well for.


I certainly respect your opinion, but would ask that you reconsider, if 
possible.


---dave

On 10/30/2015 07:06 AM, Emmanuel Bourg wrote:

Le 30/10/2015 01:42, Phil Steitz a écrit :


[X] -1 We should not do this, because...

Sorry I feel this is going too fast. I don't think Apache Commons should
turn into a forge hosting any small project asking to join. I see more
Apache Commons as a ground for gathering libraries developed in other
Apache projects. I don't think we should turn into a Github alternative
with the Apache brand.

Emmanuel Bourg


-
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] Accept Naomi

[Dave Brosius]

+1

On 10/29/2015 08:42 PM, Phil Steitz wrote:

This is a VOTE to accept the code discussed in [1] and available for
review using the git commands below.  All are welcome to vote, votes
from PMC members are binding.  Assuming a positive vote, we will
execute a software grant with the authors and use the code as the
basis for a new Commons Sandbox component.

This VOTE will close in 72 hours.  More discussion on the code and
its fit in Commons is always welcome, but please do not reply to
this thread with discussion, other than embedded justification for
negative VOTES.  Use the thread from [1] instead.

Git commands to grab the code:

git clone g...@github.com:NormanShapiro/Naomi.git
git checkout gh-pages

Thanks!

Phil
[1] http://markmail.org/message/imoi5aipf63f7rsa

[ ] +1 Yes!
[ ] +0 OK...
[ ] -0 OK, but...
[ ] -1 We should not do this, because...


-
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: Proposed Contribution to Apache Commons,

[Dave Brosius]

git clone g...@github.com:NormanShapiro/Naomi.git
git checkout gh-pages


if you like, I already have a fork on github of it, I can merge gh-pages 
into master, and delete the gh-pages branch, and then the repo will be 
obviously just a one branch project.






On 10/28/2015 08:19 PM, Phil Steitz wrote:

I am not seeing any -1s on this, so I would like to proceed with a
VOTE to accept the code and start the IP clearance process.  For
that I need a definitive snapshot of somewhere that I can point to
for the VOTE and clearance docs.  My git-foo is pretty limited.  Can
someone suggest a stable URL that we can use to identify the code
that we will be accepting, should the VOTE pass?

Thanks!

Phil

On 10/25/15 12:25 PM, dbrosIus wrote:

+1 and git please

 Original message 
From: Phil Steitz 
Date: 10/25/2015  3:15 PM  (GMT-05:00)
To: Commons Developers List 
Subject: Re: Proposed Contribution to Apache Commons,

On 10/2/15 12:08 PM, Gary Gregory wrote:

Well, a champion can volunteer to shepherd this through our incubator I
suppose,

OK, I will volunteer to do this.  I propose that we start this as a
Commons Sandbox project.  To do that, we need a VOTE to accept the
code, a software grant and the IP clearance form [1] submitted to
the Incubator PMC.  We can use either git or svn for the new sandbox
repo.

Any objections?  Any preference for git or svn?

Phil

[1] http://incubator.apache.org/ip-clearance/ip-clearance-template.html



   like CommonsRDF, which seems pretty inactive ATM. There is also
the issue of "donate and forget" vs. staying plugged in the community.

I just do not have the extra FOSS cycles to dig into the code ATM to see
what's under the hood.

Gary

On Fri, Oct 2, 2015 at 12:01 PM, Phil Steitz  wrote:


On 10/2/15 11:46 AM, Gary Gregory wrote:

I do not have time to dig into this one ATM but I'd like to give my 2c.

Does this project introduce a new RE-like language or is it an API

wrapper

for REs? It sounds like it is both.

It looks to me like what it says it is, which is an alternative to
REs, which IMO is a nice idea.  Less "pattern matching language" and
more objects expressing matching intent.  End result is less
developer thought required to accomplish a common task.  Seems to
fit nicely in Commons to me.

Phil

A project like this I could see in Commons if the project was split into

an

API module and modules for different pattern matching languages, where

the

standard Java RE would be the reference example. Naomi (I love the name
BTW, someones wife or daughter?) would be another implementation module.
With both under its belt, the project would be on fairly solid footing
(granted I do not know Naomi). You could even imaging implementations

that

would accept a JXPath or a SQL WHERE clause.

If the project is only meant to introduce a new RE-like language, then a
TLP would be probably more appropriate.

2c,
Gary

On Thu, Oct 1, 2015 at 11:58 PM, Henri Yandell 

wrote:

On Tue, Sep 29, 2015 at 5:42 PM, Phil Steitz 
wrote:


On 9/29/15 3:55 PM, Gary Gregory wrote:

Norman,

Hello and welcome to Apache Commons.

It's not clear to me why Naomi is better than regular expressions.

Pointing

to Javadocs is not the best way to get traction.

Your project would be better served by having some documentation on

your

front page with an example driven tutorial.

Is Naomi faster than REs?

What can I do in Naomi that REs can't do? And vice-versa.

Examples of this on your front page would help you at least get folks

to

consider learning a brand new way of doing things...

+1
The code in SimpleExamples starts to get to this.  Looks interesting
and powerful.  Either here or on the github readme you should take a
stab at explaining a little more how hard problems using regex get
easier with naomi, illustrated with some simple examples.  Then
maybe with help from community members here, you can develop some
overview / getting started docs that help people get into the code.


+1.

Reading SimpleExamples, my summary would be a boilerplate description of
"It replaces the arcane regular expression language with an API". It
reminds me of command line argument parsers. Perl had/has a great

regular

expression like command line argument parser, but it was cryptic and you
either loved it or hated it. Then along came Commons CLI, args4j and all
the others, providing a more OO/procedural API instead of its own mini
language. Not as 'powerful' (in that you had to type more), but simpler

(in

that you didn't have to learn a new lingo and didn't have to juggle
multiple languages inside one context (a source file)).

I definitely need that user manual. It's hard, with a brain trained on
regular expressions, to read 'Pattern greek3=new

CharSequencePattern("?")'

and realize (I think) that it means a literal ? character. It's also the
primary way it'll be successful. You need that educational path that
explains what a ExplicitCharClass is for, rather than randomly clicking

on

ja

Re: Proposed Contribution to Apache Commons,

[Dave Brosius]

Correct.

This was the branch that Mr Shapiro used when he introduced the project 
to us, so that's where i did the work. And yes, it is now merged.


My colleague Jeff Rothenberg and I, retirees, have developed an alternative to
using regular expressions for searching for (and optionally replacing)
patterns in text. We believe it is generally useful to Java programmers and
would like to contribute it to Apache Commons, where we will continue to be
active in maintaining the software. You can find the software and associated
documentation athttps://github.com/NormanShapiro/Naomi/tree/gh-pages.

Please let us know what further steps we should take to have our contribution
considered.

Thank you,

Norman Shapiro



On 10/24/2015 05:44 PM, Pascal Schumacher wrote:

Hello everybody,

the pull request was merged, but it is in the "gh-pages" branch not in 
"master", so it's not visible by default on the github page.


-Pascal

Am 24.10.2015 um 22:27 schrieb Dave Brosius:

Dear My. Shapiro,

Greetings!

Thanks for wanting to share this codebase, and making it available at 
github.


I have attempted to cleanup the repository to make it more 
approachable for others who want to take a look, including 
reorganizing the src tree and adding a proper maven build system. 
These things would make it easier to consume.


If you wouldn't mind going to

https://github.com/NormanShapiro/Naomi/pull/1

and looking at the pull request, and if acceptable, pushing the merge 
button, that would be great.


Thanks again for you source contributions,

dave.



On 10/24/2015 11:14 AM, n...@dad.org wrote:
My colleague, Jeff Rothenberg, and I are retired computer scientists 
and are
no strangers to regular expression theory and practice. Both of us 
have used
regular expressions for decades and have taught many other 
programmers how to
use them. Stephen Kleene 
(https://en.wikipedia.org/wiki/Stephen_Cole_Kleene),

the inventor of regular expressions and I
(https://en.wikipedia.org/wiki/Norman_Shapiro) were both doctoral 
students of
Alonzo Church (https://en.wikipedia.org/wiki/Alonzo_Church). 
Rothenberg used
SNOBOL3 and SNOBOL4 (more powerful than all but a few of the most 
recent

versions of regular expressions) extensively in his graduate work in
Artificial Intelligence in the late 1960 and early 1970s.

In our experience, although skilled programmers can write regular 
expressions
that solve a wide range of problems, for all but the simplest tasks 
regular
expressions quickly become "write only". That is, once they have 
aged for a
while, no one other than their authors (and, in our experience, 
often not even
they) can understand them well enough to verify, modify, debug, or 
maintain
them without considerable effort. Analogous low-level programming 
formalisms,

such as machine code and assembly language, have been replaced by
higher-level, more readable and modular languages to produce 
programs that
have proven easier and more cost-effective to debug, verify, 
maintain, reuse,

and extend.

In a similar fashion, Naomi is a means of "taming" complex regular
expressions, as well as offering an easier alternative for those who 
are
unfamiliar with them. Naomi makes pattern matching programs more 
readable,

modular, and therefore verifiable, maintainable, and extensible. Naomi
ultimately generates regular expressions, and it can do everything 
they can
do, but it provides a higher-level API that uses object-oriented 
constructs to

define complex, modular, parameterized patterns and subpatterns.

Naomi's advantages over bare regular expressions become apparent 
only for
larger scale pattern matching tasks. Whereas regular expressions are 
highly
compact and terse, this virtue becomes a vice for complex patterns. 
Coupled
with the extensive use of metacharacters and escape sequences, this 
makes even
moderately complex regular expressions effectively unreadable for 
all but the
most experienced and practiced regular expression programmers. Newer 
features
that go beyond the original regular expression formalism--such as 
namable
groups, built-in names for common character classes, comments, and 
free white
space--make regular expressions less terse. But their use is not 
enough to
render complex regular expressions easily readable. These extensions 
are
analogous to replacing binary machine language by assembly language 
coding. It
is only necessary to consider a complex problem--such as that of 
parsing the
e-mail date-time specification of RFC 2822 in src/DateTime.java--to 
appreciate
the obscurity of regular expressions and to understand Naomi's 
advantages.




 Norman Shapiro

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





-
To unsub

Re: Proposed Contribution to Apache Commons,

[Dave Brosius]

Dear My. Shapiro,

Greetings!

Thanks for wanting to share this codebase, and making it available at 
github.


I have attempted to cleanup the repository to make it more approachable 
for others who want to take a look, including reorganizing the src tree 
and adding a proper maven build system. These things would make it 
easier to consume.


If you wouldn't mind going to

https://github.com/NormanShapiro/Naomi/pull/1

and looking at the pull request, and if acceptable, pushing the merge 
button, that would be great.


Thanks again for you source contributions,

dave.



On 10/24/2015 11:14 AM, n...@dad.org wrote:

My colleague, Jeff Rothenberg, and I are retired computer scientists and are
no strangers to regular expression theory and practice. Both of us have used
regular expressions for decades and have taught many other programmers how to
use them. Stephen Kleene (https://en.wikipedia.org/wiki/Stephen_Cole_Kleene),
the inventor of regular expressions and I
(https://en.wikipedia.org/wiki/Norman_Shapiro) were both doctoral students of
Alonzo Church (https://en.wikipedia.org/wiki/Alonzo_Church). Rothenberg used
SNOBOL3 and SNOBOL4 (more powerful than all but a few of the most recent
versions of regular expressions) extensively in his graduate work in
Artificial Intelligence in the late 1960 and early 1970s.

In our experience, although skilled programmers can write regular expressions
that solve a wide range of problems, for all but the simplest tasks regular
expressions quickly become "write only". That is, once they have aged for a
while, no one other than their authors (and, in our experience, often not even
they) can understand them well enough to verify, modify, debug, or maintain
them without considerable effort. Analogous low-level programming formalisms,
such as machine code and assembly language, have been replaced by
higher-level, more readable and modular languages to produce programs that
have proven easier and more cost-effective to debug, verify, maintain, reuse,
and extend.

In a similar fashion, Naomi is a means of "taming" complex regular
expressions, as well as offering an easier alternative for those who are
unfamiliar with them. Naomi makes pattern matching programs more readable,
modular, and therefore verifiable, maintainable, and extensible. Naomi
ultimately generates regular expressions, and it can do everything they can
do, but it provides a higher-level API that uses object-oriented constructs to
define complex, modular, parameterized patterns and subpatterns.

Naomi's advantages over bare regular expressions become apparent only for
larger scale pattern matching tasks. Whereas regular expressions are highly
compact and terse, this virtue becomes a vice for complex patterns. Coupled
with the extensive use of metacharacters and escape sequences, this makes even
moderately complex regular expressions effectively unreadable for all but the
most experienced and practiced regular expression programmers. Newer features
that go beyond the original regular expression formalism--such as namable
groups, built-in names for common character classes, comments, and free white
space--make regular expressions less terse. But their use is not enough to
render complex regular expressions easily readable. These extensions are
analogous to replacing binary machine language by assembly language coding. It
is only necessary to consider a complex problem--such as that of parsing the
e-mail date-time specification of RFC 2822 in src/DateTime.java--to appreciate
the obscurity of regular expressions and to understand Naomi's advantages.



 Norman Shapiro

-
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: Proposed Contribution to Apache Commons,

[Dave Brosius]

Added a pull request with a first pass at moving all of this to a maven 
build. builds and generates javadoc fine. Might need some more fine tuning.




On 09/29/2015 08:27 PM, Dave Brosius wrote:
Also the source code is not in the proper package structure. The 
class's have packages, but are just dumped directly in src. There is 
javadoc, but just dumped in the main folder. I just dump that, and 
having support building the javadoc from build tools. Setting the 
structure of the project up into some sane will help get people to 
look at it. I'd again strongly recommend getting this into a maven 
standard project format.


If you want help putting this project into a healthy state, 
layout/build wise let me know, i could spare a few cycles.


--dave

On 09/29/2015 08:11 PM, Dave Brosius wrote:
Perhaps i am blind, but i don't see any maven, ant or gradle build 
files. You really need to add these for your code base to be 
accessible to others wanted to uptake it. (Hopefully maven).


--dave

On 09/29/2015 06:55 PM, Gary Gregory wrote:

Norman,

Hello and welcome to Apache Commons.

It's not clear to me why Naomi is better than regular expressions. 
Pointing

to Javadocs is not the best way to get traction.

Your project would be better served by having some documentation on 
your

front page with an example driven tutorial.

Is Naomi faster than REs?

What can I do in Naomi that REs can't do? And vice-versa.

Examples of this on your front page would help you at least get 
folks to

consider learning a brand new way of doing things...

Gary



On Tue, Sep 29, 2015 at 1:06 PM,  wrote:


My colleague Jeff Rothenberg and I, retirees, have developed an
alternative to
using regular expressions for searching for (and optionally replacing)
patterns in text. We believe it is generally useful to Java 
programmers and
would like to contribute it to Apache Commons, where we will 
continue to be

active in maintaining the software. You can find the software and
associated
documentation at https://github.com/NormanShapiro/Naomi/tree/gh-pages.

Please let us know what further steps we should take to have our
contribution
considered.

Thank you,

 Norman Shapiro

-
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: Proposed Contribution to Apache Commons,

[Dave Brosius]

Also the source code is not in the proper package structure. The class's 
have packages, but are just dumped directly in src. There is javadoc, 
but just dumped in the main folder. I just dump that, and having support 
building the javadoc from build tools. Setting the structure of the 
project up into some sane will help get people to look at it. I'd again 
strongly recommend getting this into a maven standard project format.


If you want help putting this project into a healthy state, layout/build 
wise let me know, i could spare a few cycles.


--dave

On 09/29/2015 08:11 PM, Dave Brosius wrote:
Perhaps i am blind, but i don't see any maven, ant or gradle build 
files. You really need to add these for your code base to be 
accessible to others wanted to uptake it. (Hopefully maven).


--dave

On 09/29/2015 06:55 PM, Gary Gregory wrote:

Norman,

Hello and welcome to Apache Commons.

It's not clear to me why Naomi is better than regular expressions. 
Pointing

to Javadocs is not the best way to get traction.

Your project would be better served by having some documentation on your
front page with an example driven tutorial.

Is Naomi faster than REs?

What can I do in Naomi that REs can't do? And vice-versa.

Examples of this on your front page would help you at least get folks to
consider learning a brand new way of doing things...

Gary



On Tue, Sep 29, 2015 at 1:06 PM,  wrote:


My colleague Jeff Rothenberg and I, retirees, have developed an
alternative to
using regular expressions for searching for (and optionally replacing)
patterns in text. We believe it is generally useful to Java 
programmers and
would like to contribute it to Apache Commons, where we will 
continue to be

active in maintaining the software. You can find the software and
associated
documentation at https://github.com/NormanShapiro/Naomi/tree/gh-pages.

Please let us know what further steps we should take to have our
contribution
considered.

Thank you,

 Norman Shapiro

-
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: Proposed Contribution to Apache Commons,

[Dave Brosius]

Perhaps i am blind, but i don't see any maven, ant or gradle build 
files. You really need to add these for your code base to be accessible 
to others wanted to uptake it. (Hopefully maven).


--dave

On 09/29/2015 06:55 PM, Gary Gregory wrote:

Norman,

Hello and welcome to Apache Commons.

It's not clear to me why Naomi is better than regular expressions. Pointing
to Javadocs is not the best way to get traction.

Your project would be better served by having some documentation on your
front page with an example driven tutorial.

Is Naomi faster than REs?

What can I do in Naomi that REs can't do? And vice-versa.

Examples of this on your front page would help you at least get folks to
consider learning a brand new way of doing things...

Gary



On Tue, Sep 29, 2015 at 1:06 PM,  wrote:


My colleague Jeff Rothenberg and I, retirees, have developed an
alternative to
using regular expressions for searching for (and optionally replacing)
patterns in text. We believe it is generally useful to Java programmers and
would like to contribute it to Apache Commons, where we will continue to be
active in maintaining the software. You can find the software and
associated
documentation at https://github.com/NormanShapiro/Naomi/tree/gh-pages.

Please let us know what further steps we should take to have our
contribution
considered.

Thank you,

 Norman Shapiro

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







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

Re: [Math] Utilitzation of SLF4J?

[Dave Brosius]

slf4j-api.jar also has no required dependencies.

On 09/26/2015 06:14 PM, Ralph Goers wrote:

The Log4j API has no dependencies.  Log4j-core only requires log4j-api.  It has 
lots of optional features and so has lots of optional dependencies, but none 
are required.

Ralph



On Sep 26, 2015, at 1:09 PM, Luc Maisonobe  wrote:

Le 26/09/2015 21:49, Romain Manni-Bucau a écrit :

Le 26 sept. 2015 12:07, "Luc Maisonobe"  a écrit :

Le 26/09/2015 20:59, Ralph Goers a écrit :

I don’t normally participate in Math but I do feel the need to stick my

nose in here.

1. You are absolutely correct to determine whether you need logging at

all before discussing what to choose.

2. If you do decide logging is required:
  a. Please stay away from java.util.logging. It really would be the

best solution for a framework like math except it is extremely difficult to
redirect efficiently to some other logging framework. The methods used by
SLF4J and Log4j are imperfect to say the least.

  b. Log4j 1.x has reached eol. It effectively has not been supported

for 5 years.

  c. Log4j 2 has an API that can be redirected to another logging

framework if desired.

  d. Commons logging still works but its API is very primitive by

todays standards. That said, it does work.

 From what I have seen, if I ever were to choose a logging framework for
any project, I agree log4j 2 is currently the best choice. I was
impressed by slf4j a few years ago, but think now the step further is
log4j 2 (without any accurate reason, just a rough feeling).


And in 2 years foolog4j will be better. JUL is not perfect for sure but
ensures:
- no dep
- always usable
- allows to let the user integrate with the lib without having to fork it
to get rid of a logging dep - think to tomee which consumes N commons deps,
if all uses a different logging framework it is worse to configure and
highly inconsistent - that is why we chose jul by default

That is for the logging framework choice.
Now commons shouldnt log much IMO otherwise it would start to loose commons
in sense of shareable component cause of the integration issues it
generates in the final application.

Big +1 to this. For the [math] case (and commons at whole), dependencies
should be avoided. In fact looking at log4j pom (even the core pom) one
can notice it depends on several commons components. This makes me think
more and more that commons components are the lowest possible level,
just above java itself.

So I think my message above was already out of scope. It may apply to
some applications, but not to commons.

thanks for reminding me about that, Romain!

best regards,
Luc


- Romain


best regards,
Luc


Ralph



On Sep 26, 2015, at 10:07 AM, Luc Maisonobe  wrote:

Le 26/09/2015 18:42, Gilles a écrit :

On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:

On 9/26/15 4:56 AM, Thomas Neidhart wrote:

On 09/26/2015 01:11 PM, Gilles wrote:

On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:

On 09/26/2015 02:33 AM, Gilles wrote:

On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:

On 25 September 2015 at 16:47, Gilles <

gil...@harfang.homelinux.org>

wrote:


On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:


On Fri, Sep 25, 2015 at 5:09 PM, Gilles

wrote:

On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:

On 9/25/15 7:03 AM, Gilles wrote:

On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:

Hi Ole,

for a start, I think you are asking the wrong question.
First of all we need to agree that we want to add some

kind of

logging
facility to CM.
If the outcome is positive, there are a handful of
alternatives,
some of
them more viable than slf4j in the context of CM (e.g.

JUL or

commons-logging).



Could someone summarize why those alternatives were deemed
"more
viable"?

btw. the same discussion has been done for other commons


components as
well, and the result usually was: do not add logging



What was the rationale?



Look at the archives.  We have discussed this multiple times
in the
past in [math] and each time came to the conclusion that

Thomas

succinctly states above.  What has changed now?



We also discussed several times to stick with Java 5.
Fortunately, that has changed. [Although sticking with Java

7 is

still
a bad decision IMHO.]

As for logging, IIRC, the sole argument was "no dependency"
because
(IIRC) of the potential "JAR hell".



that's not correct. The decision to not include any
dependencies has
nothing to do with "JAR hell".


Although I can't find it now, I'm pretty sure that I more than

once

got such an answer.

In order to prevent JAR hell, commons components strictly stick
to the

"Versioning guidelines" [1]


I can't see how it relates.
But if you mean that no JAR hell can emerge from using a

logging

framework,
then that's good news.

The no-dependency rule is more related to the proposal of the
component,

see [2]


Thanks for the reminder; in that document, we read:

(1) Scope of the Package
  [...]
  5. Limited 

Re: svn commit: r1697267 - in /commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6: classfile/ generic/ verifier/structurals/

[Dave Brosius]

Revert if you like. I'm not sure how it breaks anything. The return type 
is not part of a method signature, so it doesn't break reflection. You 
can override with a method that returns Object. You can assign to 
object. so not sure the issue. But it's not a big deal so, whatever.


On 09/09/2015 01:41 PM, sebb wrote:

On 9 September 2015 at 17:57, Gary Gregory  wrote:

On Wed, Sep 9, 2015 at 1:19 AM, sebb  wrote:


PING.

If I don't hear any response in the next few days I will revert.


Would it be helpful to post a link to what a -1 on a commit means as a
refresher?

By all means.


Gary



On 3 September 2015 at 14:43, sebb  wrote:

@dbros...@apache.org

This commit still needs to be reverted please.

Whilst it makes calling clone slightly easier, it breaks binary and
source compatibility.
The downsides are not worth the convenience.

On 24 August 2015 at 11:18, sebb  wrote:

The clone method and Cloneable interface should be treated with
caution [1], so I don't think it makes sense to make it easier to use.

I would rather see copy methods allied to a suitable interface.

[1] http://my.safaribooksonline.com/9780137150021/ch03lev1sec4

On 24 August 2015 at 11:07, sebb  wrote:

On 24 August 2015 at 10:57, Jörg Schaible <

joerg.schai...@swisspost.com> wrote:

Hi Sebb,

sebb wrote:


On 24 August 2015 at 08:04, Jörg Schaible <

joerg.schai...@swisspost.com>

wrote:

Hi Sebb,

sebb wrote:


On 23 August 2015 at 23:19,   wrote:

Author: dbrosius
Date: Sun Aug 23 22:19:04 2015
New Revision: 1697267

URL: http://svn.apache.org/r1697267
Log:
remove the need for casting at the clone() call site

-1

I was hoping to reduce the number of API changes to the minimum,

so we

can potentially release a
version that is binary compatible with 5.2.

Are you sure that this is binary incompatible? IIRC it is safe to

adjust

the return type of clone here.

It's not binary compatible because the return type is part of the
method signature.

I think it may well be source compatible.

No, because the exception is no longer thrown (error depends on the

compiler

settings)

Huh? The commit did not change the throws clauses (there were none)


or if someone has overloaded the method with return type Object.

Here I agree.


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




--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

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: svn commit: r1697267 - in /commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6: classfile/ generic/ verifier/structurals/

[Dave Brosius]

Revert if you like. I'm not sure how it breaks anything.

On 09/09/2015 01:41 PM, sebb wrote:

On 9 September 2015 at 17:57, Gary Gregory  wrote:

On Wed, Sep 9, 2015 at 1:19 AM, sebb  wrote:


PING.

If I don't hear any response in the next few days I will revert.


Would it be helpful to post a link to what a -1 on a commit means as a
refresher?

By all means.


Gary



On 3 September 2015 at 14:43, sebb  wrote:

@dbros...@apache.org

This commit still needs to be reverted please.

Whilst it makes calling clone slightly easier, it breaks binary and
source compatibility.
The downsides are not worth the convenience.

On 24 August 2015 at 11:18, sebb  wrote:

The clone method and Cloneable interface should be treated with
caution [1], so I don't think it makes sense to make it easier to use.

I would rather see copy methods allied to a suitable interface.

[1] http://my.safaribooksonline.com/9780137150021/ch03lev1sec4

On 24 August 2015 at 11:07, sebb  wrote:

On 24 August 2015 at 10:57, Jörg Schaible <

joerg.schai...@swisspost.com> wrote:

Hi Sebb,

sebb wrote:


On 24 August 2015 at 08:04, Jörg Schaible <

joerg.schai...@swisspost.com>

wrote:

Hi Sebb,

sebb wrote:


On 23 August 2015 at 23:19,   wrote:

Author: dbrosius
Date: Sun Aug 23 22:19:04 2015
New Revision: 1697267

URL: http://svn.apache.org/r1697267
Log:
remove the need for casting at the clone() call site

-1

I was hoping to reduce the number of API changes to the minimum,

so we

can potentially release a
version that is binary compatible with 5.2.

Are you sure that this is binary incompatible? IIRC it is safe to

adjust

the return type of clone here.

It's not binary compatible because the return type is part of the
method signature.

I think it may well be source compatible.

No, because the exception is no longer thrown (error depends on the

compiler

settings)

Huh? The commit did not change the throws clauses (there were none)


or if someone has overloaded the method with return type Object.

Here I agree.


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




--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

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] Move COMPRESS to git

[Dave Brosius]

+1

On 08/22/2015 03:29 PM, Stefan Bodewig wrote:

Hi all

more thann half a year ago I promised to call for a vote for migrating
to git as soon as 1.10 has been released.  Well that took longer than
expected :-)

Anyway, here is the vote:

+1 Move to git
-1 Stick with svn

vote will be open for 72 hours

Cheers

 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] Release BCEL 6.0 based on RC4

[Dave Brosius]

yes. definitely.

On 08/11/2015 01:34 PM, Gary Gregory wrote:

Is the org.apache.bcel.classfile.Visitor

interface
something a user would implement?
Gary

On Mon, Aug 10, 2015 at 9:52 PM,  wrote:


For those asking for a CLIRR, I have created one base upon RC3:

https://people.apache.org/~chas/bcel-6.0-RC3/clirr-report.html

regards,
chas



-
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 BCEL 6.0 based on RC4

[Dave Brosius]

I'm not sure having the 6 in bcel6 is such a good idea. the prefix 
already disambiguates the package name, so this isn't needed and is kind 
of limiting.


On 08/10/2015 06:49 AM, sebb wrote:

Assuming that the package name change is required, then there are also
a lot of mutable non-private fields that need to be made private.

I am happy to make these changes, but I don't wish to change the API
until the need for a break is established.

On 10 August 2015 at 11:22, sebb  wrote:

I am currently -1 because of:

Several uses of deprecated methods and classes.
Given that there is a new package name/Maven id, now is the time to
remove any deprecated items.

There is some very strange code in Utility.java:
865 & 868:consumed_chars = ++consumed_chars;

There may be some other issues; I need to have a further look.

On 10 August 2015 at 04:55,   wrote:

  The last BCEL release (5.2) occurred in February of 2006.  It’s been nine
years since the last release and four years since the code was transferred
to commons.  Over this time, java byte code has been enhanced with
additional opcodes and dynamic language support.  Supporting these byte code
changes is the most significant feature of BCEL-6.0.

   BCEL 6.0 RC4 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/bcel (svn revision 10111)

   Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1104/org/apache/commons/commons-bcel6/6.0/

   Details of changes since 5.2 are in the release notes:
 https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
 https://people.apache.org/~chas/bcel-6.0-RC4/changes-report.html

   I have tested this with JDK 1.7 using maven3.

   The tag is here:
 http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC4/
(svn revision 1694950)

   Site:
 https://people.apache.org/~chas/bcel-6.0-RC4/
   (note some *relative* links are broken - these should be OK once the site
is deployed)

   Clirr Report:
 N/A

   RAT Report:
 https://people.apache.org/~chas/bcel-6.0-RC4/rat-report.html

   KEYS:
   https://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 1800 GMT
12 August 2015

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

Thanks!
Chas


-
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: [pool] apparently bad jar released ... ugh. help!

[Dave Brosius]

Yeah, can't pull it back. Just need to push a new version.

On 05/27/2015 05:57 PM, Phil Steitz wrote:

Somehow the 2.4 binary release jar that I just pushed to the mirrors
and maven central appears to be corrupted.  I don't know why / how
this happened but I get the following error when I build dbcp with
the new jar:

net/sourceforge/cobertura/coveragedata/TouchCollector
java.lang.NoClassDefFoundError:
net/sourceforge/cobertura/coveragedata/TouchCollector
 at
org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java)

There is also a coberta.properties file in the manifest.  I have no
idea how it happened, but somehow maven seems to have created the
release jar from the coberta-instrumented classes or something.

The hashes and sigs on the jar are all good.

I would appreciate some help figuring out what is going on here and
also pushing out a quick fix release, as I suspect there is no way
we can pull back what I pushed out about 10 hours ago.

Sorry to have not caught this prior to pushing the binaries out and
thanks in advance for any help anyone can provide.

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

Re: [bcel] PLSE changes to BCEL

[Dave Brosius]

6.0 already has breaking changes, thus the move to version 6.0.

One specific case is that annotations are now coming in as annotations 
as opposed to unknown code attributes. Code that relies on parsing 
annotations thru unknown code attributes will break.




On 02/23/2015 07:30 AM, Ben McCann wrote:

Ok, thanks. The part I wasn't sure about is if that was the only breaking
change. It sounds like you're saying the other changes aren't breaking.

-Ben
On Feb 22, 2015 11:14 PM, "Emmanuel Bourg"  wrote:


Le 23/02/2015 05:39, Ben McCann a écrit :


Are many of your changes breaking backward compatibility? I'm wondering

if

there are only a few that do if we could prioritize them in order to get

a

6.0 release out with the rest of the changes coming in a 6.1.

Hi Ben,

I think we already answered this question, BCEL-209 is a breaking change
because it affects the public API. Your help resolving this issue would
be welcome. We have to understand why the current design was chosen and
if the design proposed by Mark may cause any issue later.

Emmanuel Bourg


-
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 BCEL 6.0 based on RC3

[Dave Brosius]

+1
On 10/08/2014 01:54 PM, Jörg Schaible wrote:

+1

builds from source-tarball with my complete compiler zoo

Emmanuel Bourg wrote:


Hi all,

The third release candidate of BCEL is ready to pass under your scrutiny.

Tag:
http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC3/
(r1627908)

Release notes:
http://people.apache.org/~ebourg/bcel/RELEASE-NOTES.txt

Distribution files:
http://people.apache.org/~ebourg/bcel/

Checksums (sha1):
6f1d11224b7cea98ffbffa25d69d759fcd47421c  bcel-6.0-bin.tar.gz
425729b886f72481bdbfc7e8ca108f20c00e67ef  bcel-6.0-bin.zip
89e171be63df397d23ea746f9845cf3087e8467e  bcel-6.0-src.tar.gz
a03c2e605b8eb997b5d023d6a7d6aa54fbf3600e  bcel-6.0-src.zip

Site:
http://people.apache.org/~ebourg/bcel/site/

Javadoc:
http://people.apache.org/~ebourg/bcel/site/apidocs/

Maven artifacts:


https://repository.apache.org/content/repositories/orgapachecommons-1047/org/apache/bcel/bcel/6.0/


Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

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

Thank you for your reviews,

Emmanuel Bourg



-
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 BCEL 6.0 based on RC1

[Dave Brosius]

+1
On 09/18/2014 08:44 PM, sebb wrote:

On 19 September 2014 00:14, Emmanuel Bourg  wrote:

Hi all,

The first release candidate of BCEL is ready to pass under your scrutiny.

Tag:
http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC1/
(r1621539)

Release notes:
https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt

Distribution files:
https://dist.apache.org/repos/dist/dev/commons/bcel/

I assume that is Revision 6553 ?

[Either the rev or hashes are needed in the vote e-mail so the final
released artifacts can be traced back to the vote if necessary]

Also the KEYS file needs to be in the e-mail; I assume it is:

http://www.apache.org/dist/commons/bcel/KEYS


Site:
http://people.apache.org/~ebourg/bcel/site/

Javadoc:
http://people.apache.org/~ebourg/bcel/site/apidocs/

Maven artifacts:
https://repository.apache.org/content/repositories/orgapachecommons-1044/org/apache/bcel/bcel/6.0/


Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

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

Thank you for your reviews,

Emmanuel Bourg


-
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: [BCEL] Trying a release?

[Dave Brosius]

I think the driving thing is that it is bumped up to jdk1.5 from 1.4


On 08/25/2014 05:08 PM, Emmanuel Bourg wrote:

Le 22/08/2014 12:12, Stefan Bodewig a écrit :


If BCEL6 can be used as a drop in replacement, then not changing the
coordinates might be a good idea (but begs the question of why it has a
new major version).

I asked about the next version number back in April and the consensus
was that a major version change better reflected the amount of changes
since the last release.

Emmanuel Bourg

-
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: [BCEL] Trying a release?

[Dave Brosius]

+1

On 08/22/2014 02:54 AM, Benedikt Ritter wrote:

I've uploaded the current site of BCEL to my apache space:
http://people.apache.org/~britter/bcel-6.0-SNAPSHOT/

We have 12 clirr errors, because some methods have been added to the
org.apache.bcel.classfile.Visitor
interface. Since we already bumped the major version number vom 5 to 6,
since seems to be a good opportunity to change the groupId from
org.apache.bcel to org.apache.commons and the artifactId from bcel to
commons-bcel

WDYT?

Benedikt


2014-08-22 7:44 GMT+02:00 Benedikt Ritter :


Hi guys,

several projects are waiting for a Java 8 compatible BCEL release and
since nobody else seems to have the time to do it, I'll have a look at it
this weekend. Please let me know if you see anything that needs fixing.

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: [bcel] Next release

[Dave Brosius]

I think it should be 6.0 since we've changed from requiring jdk1.4 to 
jdk1.5 and that really shouldn't be done on a point release.


---


On 2014-04-25 08:57, Gary Gregory wrote:

Either version # is fine with me.

Gary


On Fri, Apr 25, 2014 at 8:40 AM, Torsten Curdt  
wrote:



Go go go! Thanks for looking into this :)

IIRC there is so much stuff fixed and changed from 5.2 - I think
calling it 6.0 expresses this better than 5.3.
Especially with the changes to the visitor interface.

cheers,
Torsten

On Fri, Apr 25, 2014 at 12:30 PM, Emmanuel Bourg 
wrote:
> Hi all,
>
> I'm currently working on the migration to Java 8 in Debian and several
> packages are broken due to the lack of invokedynamic support in BCEL 5.2
> (the dreaded ClassFormatException: Invalid byte tag in constant pool:
> 18). I think it's high time for a release. Even if the current code
> isn't perfect it's far better than BCEL 5.2 (there are ~60 issues fixed
> in JIRA).
>
> The code on the trunk isn't fully compatible with the previous release
> due to the addition of methods to the Visitor interface. By Commons
> standards we would usually change the package, however I think it's safe
> to keep the org.apache.bcel package as is. The Visitor interface is
> never implemented directly, I have found that projects always extend the
> EmptyVisitor class instead. I've rebuilt several projects using BCEL
> (ant, ant-contrib, clirr, clirr-maven-plugin, ha-jdbc, jbossas, jibx,
> mx4j, xalan, maven-shared-jar, robocode) and they all worked fine with
> the current snapshot.
>
> The code on the trunk is numbered 6.0, are we ok with that or should we
> use 5.3 for the next release?
>
> Emmanuel Bourg
>
> -
> 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: [ANNOUNCE] Commons Email version 1.3.2 released

[Dave Brosius]

Robert, send an email to

dev-unsubscr...@commons.apache.org

*http://tinyurl.com/njw7snw


*
On 10/26/2013 01:08 AM, Robert Hood wrote:

please remove me from the list


On Thu, Oct 24, 2013 at 11:28 PM, Thomas Neidhart  wrote:


Hello.

The Apache Commons team is pleased to announce the release of
commons-email-1.3.2.

Commons-Email aims to provide an API for sending email. It is built on
top of the JavaMail API, which it aims to simplify.

Commons Email can be downloaded from the following page:
   http://commons.apache.org/email/download_email.cgi

For information on Commons Email, please visit our website:
   http://commons.apache.org/email/

Details of the changes and bug fixes in this release can be found in the
release notes:
   http://www.apache.org/dist/commons/email/RELEASE-NOTES.txt

The changes are also available at:
   http://commons.apache.org/email/changes-report.html

Commons Email now requires Java 5 or later.

The Maven coordinates are:
 org.apache.commons
 commons-email
 1.3.2

Best regards,

Thomas, on behalf of the Apache Commons community

Re: [VOTE] Move Apache Commons to Git for SCM...

[Dave Brosius]

Those who wanted to move to Git have given up several days ago, leaving 
this thread to be 'argued' by
those who successfully squashed the action. James has already canceled 
the test project request in INFRA, and
so it seems pointless for this thread to continue. You won, go off and 
have a beer, and enjoy.


On 10/16/2013 11:56 PM, Henri Yandell wrote:

There's no veto notion here - if we're abiding by the lowest denominator of
the base Apache voting rules, vetoes are only for code votes. While this is
to do with code, it's not code itself.

I see it settled in that an understanding is reached.

The majority of those voting have indicated that they have a preference for
git over svn and would like Commons to move in that direction.

I'm definitely confused by the proposal. Being selfish - what's this going
to change? The discussion implied code review would be used (are we moving
to RTC?). It implied that there would be issues in checking all of Commons
out (which has always been very important to me, though I'll admit not
right now as I've not been supporting cross-Commons features the way
others, noticeably Sebb, are). If we break the ability for someone to fix
issues across all components, we increase the likelihood that central
changes won't be pushed out. Will GitHub pull requests get better? Because
they're currently a mess. Will we lose existing contributors due to putting
a hurdle in their way? Will the development workflow change? While I use
git at the moment, I'm aware I use it in an svn way because I'm always
hitting pains where git's support for my workflow involves doing odd items
(acknowledging the issue is me for not developing in a git way). If we move
a component to git, will I still be able to commit to it via some form of
svn2git bridge, or will each partial migration mean a component vanishing
from trunks-proper?

Browsing the git discuss thread, it was surprisingly light on details. To
be excited by this and not feel frustrated, I suspect I'll need more
support (explanations before hand, answers to dumb questions). However this
seems much like the moves to maven1 and maven2. A difference to the
maven1/maven2 moves is that they were done with overlap. Components were
not unusual to have Ant, Maven 1 and Maven 2 build systems.

Summary: I won't add my vote because I don't understand the question. We're
not voting on moving to Git, we're voting on something bigger and only
those voting +1 know what that is :) I'm not against it, but I know there
will be pain, someone else is going to do all the work [hey, I served my
time on jira and svn] and I'll slowly catch up and hopefully not get lost
along the way :)

---

An aside: I'm not convinced btw that another thread entitled "[VOTE] Stay
on Subversion" wouldn't also be passed. To conjecture culturally, those
fastest to respond are most likely to want to move to Git, while those
slower are most likely to want to stay on Subversion. Mobilization of the
SVN vote would probably exceed the Git vote, however I believe there is a
level of those interacting more often with the scm having a greater voice
in the choice of system being interacted with.

Hen


On Wednesday, October 16, 2013, James Ring wrote:


So did any committer want to exercise a veto? Otherwise the matter is
settled right?
On Oct 16, 2013 6:38 PM, "sebb"  wrote:


On 17 October 2013 02:10, Ralph Goers 

wrote:

On Oct 16, 2013, at 2:46 PM, James Ring wrote:


Do Apache by-laws require a quorum? Was there a quorum for this vote?


Apache voting rules are documented at

http://www.apache.org/foundation/voting.html. However, that page doesn't
define "consensus" which is where some of the disagreement came from.

It's defined in the glossary:

http://www.apache.org/foundation/glossary.html#ConsensusApproval

-
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: [CHALLENGE] Move All of Commons to the Dormant

[Dave Brosius]

I couldn't disagree more. Dormant/attic means the project has leprosy. I 
don't know the answer to this, but wondering, has there ever been a 
commit to an attic'ed project? I personally would never think of doing that.




On 10/15/2013 01:22 AM, Benedikt Ritter wrote:



Am 15.10.2013 um 07:14 schrieb Dave Brosius :

Perhaps for new users, however there are lots of projects currently using these 
libraries. We are extending the middle finger to them by doing this. I would 
come away thinking i'm not going to risk using any Apache library, if I they 
will  just yank away the next project i choose to use sometime in the near 
future. I'm fine with putting a message on the site that says, this project is 
in desperate need of supporters, developers, testers, documentation folks, etc, 
etc. without which maintenance and support will be next to impossible. That 
would warn new users fairly enough imo.

That's basically what dormant means...


dave



A project is only one of these clients needing a fix away from re-engaging.

On 10/15/2013 12:59 AM, Henri Yandell wrote:

Three values jump out to me:

* First is for our users. Having code available that no one is supporting
while giving the appearance of support (ie: active Commons) is a bad
experience.
* Second (generally for the ASF) is that if we have code we can't maintain,
because there is no one who can handle some critical issue, then we
shouldn't be treating it as a live project. That's always been something
Commons could get around by knowing that some of the committers will dig
into unknown component A and figure out what the critical issue is in the
rare times it's come up.
* Third is that it provides focus to not be trying to fix all of the
inactive components when we change the build or site. Though perhaps we
just leave it all broken anyway :)

Hen


On Mon, Oct 14, 2013 at 9:40 PM, Dave Brosius  wrote:

I vote -1 to this process. I see no value in attic-izing projects.





On 10/14/2013 11:55 PM, Henri Yandell wrote:

I contend that all of the Commons components are inactive and should move
to the Attic/Dormant. In line with Phil's recent suggestion that anyone
can
present a dormancy challenge at any time, I'm challenging all of Commons
Proper.

I've made a file in SVN:

  https://svn.apache.org/repos/**asf/commons/trunks-proper/**
CHALLENGE.txt<https://svn.apache.org/repos/asf/commons/trunks-proper/CHALLENGE.txt>

If committers could put their ids next to components they actively monitor
the commits, JIRA, mailing list for, then we can determine, by
elimination,
the components that should be considered for dormancy.

I propose we review the state of the file at the start of November :)

Hen

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


-
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: [CHALLENGE] Move All of Commons to the Dormant

[Dave Brosius]

Perhaps for new users, however there are lots of projects currently 
using these libraries. We are extending the middle finger to them by 
doing this. I would come away thinking i'm not going to risk using any 
Apache library, if I they will  just yank away the next project i choose 
to use sometime in the near future. I'm fine with putting a message on 
the site that says, this project is in desperate need of supporters, 
developers, testers, documentation folks, etc, etc. without which 
maintenance and support will be next to impossible. That would warn new 
users fairly enough imo.


dave



A project is only one of these clients needing a fix away from re-engaging.

On 10/15/2013 12:59 AM, Henri Yandell wrote:

Three values jump out to me:

* First is for our users. Having code available that no one is supporting
while giving the appearance of support (ie: active Commons) is a bad
experience.
* Second (generally for the ASF) is that if we have code we can't maintain,
because there is no one who can handle some critical issue, then we
shouldn't be treating it as a live project. That's always been something
Commons could get around by knowing that some of the committers will dig
into unknown component A and figure out what the critical issue is in the
rare times it's come up.
* Third is that it provides focus to not be trying to fix all of the
inactive components when we change the build or site. Though perhaps we
just leave it all broken anyway :)

Hen

On Mon, Oct 14, 2013 at 9:40 PM, Dave Brosius  wrote:


I vote -1 to this process. I see no value in attic-izing projects.




On 10/14/2013 11:55 PM, Henri Yandell wrote:


I contend that all of the Commons components are inactive and should move
to the Attic/Dormant. In line with Phil's recent suggestion that anyone
can
present a dormancy challenge at any time, I'm challenging all of Commons
Proper.

I've made a file in SVN:

  https://svn.apache.org/repos/**asf/commons/trunks-proper/**
CHALLENGE.txt<https://svn.apache.org/repos/asf/commons/trunks-proper/CHALLENGE.txt>

If committers could put their ids next to components they actively monitor
the commits, JIRA, mailing list for, then we can determine, by
elimination,
the components that should be considered for dormancy.

I propose we review the state of the file at the start of November :)

Hen



--**--**-
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: [CHALLENGE] Move All of Commons to the Dormant

[Dave Brosius]

I vote -1 to this process. I see no value in attic-izing projects.



On 10/14/2013 11:55 PM, Henri Yandell wrote:

I contend that all of the Commons components are inactive and should move
to the Attic/Dormant. In line with Phil's recent suggestion that anyone can
present a dormancy challenge at any time, I'm challenging all of Commons
Proper.

I've made a file in SVN:

 https://svn.apache.org/repos/asf/commons/trunks-proper/CHALLENGE.txt

If committers could put their ids next to components they actively monitor
the commits, JIRA, mailing list for, then we can determine, by elimination,
the components that should be considered for dormancy.

I propose we review the state of the file at the start of November :)

Hen




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

[Dave Brosius]

in the spirit of better late than never

+1 - yes, move to Git



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

[Dave Brosius]

Phil,

You definitely have a point, but nothing helps build a development 
community than seeing releases go out.


"I want to be part of that"

If there's no idea if or even when another version of a library will go 
out, especially one that's hasn't released in a while, it deflates 
possible joiners.


Even if we *just* released generized versions of the existing versions 
and nothing else, that would be really helpful, i think, in pulling in 
more help.


--dave


On 10/06/2013 04:53 PM, Phil Steitz wrote:



On Oct 6, 2013, at 1:46 PM, Phil Steitz  wrote:




On Oct 6, 2013, at 12:00 PM, James Carman  wrote:

The fact that it has taken so long before we got something out for
Collections 4.x is just an embarrassment.  How long has Java had
generics?  What could be causing us to be so slow to get releases out?

I may be in the minority here, but I think the real problem is too many components for 
too few "committed committers". The release process has always been a little 
bit of a pain in the butt, but I've never felt blocked by it.  What has taken so long on 
pool/DBCP is that it is just Mark and I really digging into the code and we are both busy 
with other stuff / have limited time to work on it. Like some other components, the code 
is also kind of specialized and the documentation is not the best, making it harder for 
others to get involved. Collections went nowhere for a couple of years because no one 
stepped up to drive it.  Thankfully Thomas did recently and we got a 4.0 beta.  The best 
thing anyone can do to get a real 4.0 out is start actually coding on it.

I honestly think we are making excuses in this thread - the real problem is 
dwindling component communities.  We need to decide which ones to ale dormant 
and make it easier for people to get involved in the active ones.

S/ale/make (love that iPhone :)



On Sun, Oct 6, 2013 at 2:57 PM, Phil Steitz  wrote:
On 10/6/13 11:45 AM, James Carman wrote:
Collections 4.x, nuff said

Huh?  Didn't we release a beta?  We could say the same thing about
math 4.0, pool/dbcp 2.0, etc.  These things are in progress.  They
will get released.  There is activity.  I don't get the big problem
here.

Phil


On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum
 wrote:

I would like to know the metrics for that conclusion. I see plenty of
discussions and commits, but I'm not seeing any languishing.

Adrian Crum
Sandglass Software
www.sandglass-software.com



On 10/6/2013 11:30 AM, 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

-
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: [DISCUSS] promotion and release of [weaver] component

[Dave Brosius]

On 09/17/2013 04:40 PM, Matt Benson wrote:

I propose that the [weaver] component [1] is ready for release.  I am the
primary contributor to the code, but Mark Struberg also worked on the core
architecture.  As soon as [weaver] is released I intend to incorporate the
privilizer module into Apache BVal, and at least at one point it was
planned that it would be similarly used in Apache OpenWebBeans, so
hopefully these will reduce its risk of being orphaned.  Does anyone have
any concerns before I put the promotion of [weaver] to a proper component
to a vote?

Thanks,
Matt

[1] https://commons.apache.org/sandbox/commons-weaver/index.html



should the class loader creation in WeaveProcessor/CleanProcessor be 
done in a AccessController.doPrivileged block?


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

MannWhitneyUTest.mannWhitneyU

[Dave Brosius]

I would think that in

public double mannWhitneyU(final double[] x, final double[] y)



final double U1 = sumRankX - (x.length * (x.length + 1)) / 2;


should be


final double U1 = sumRankX - (x.length * (x.length + 1)) / 2*.0*;


right?

Re: ObjectUtils

[Dave Brosius]

Nice. Seems like the right solution.

On 07/04/2013 11:20 PM, Julien Aymé wrote:

Hi,

Instead of using a predicate, wouldn't it be simpler to just use
if (false == Arrays.asList(obj1, obj2, ...).contains(null)) ?

Just my 2 cents,
Julien

2013/7/5 Romain Manni-Bucau :

Hi

I'd just provide a IsNullPredicate class (a singleton) and then use
commons-collection to select the subcollection and if size is 0 or original
size (depend what you test) it would be true

That said with next java version it will be quite useless IMO
Le 4 juil. 2013 22:04, "Rafael Santini"  a écrit :


Hi Ted,

I have some codes that needs to test whether a set of objects are all true
or not. For example:

if (obj1 != null && obj2 != null && obj3 != null && obj4 != null) {
// Do something...
}

So, for readability reason, I have replaced for:

if (isNotTrue(obj1, obj2, obj3, obj4) {
// Do something...
}

So I would like something like the isNotNull(Object... objects) method in
Commons Lang instead of maintain this method in my own framework.

Thanks,

Rafael Santini

-Mensagem Original- From: Ted Dunning
Sent: Thursday, July 04, 2013 4:34 PM
To: Commons Developers List
Subject: Re: Lang: ObjectUtils

A bigger question is why this is needed at all.

Why not just use composition?  In guava, one would do this:

Iterables.all(Arrays.asList(**foo), new Predicate() {
@Override
public boolean apply(Double input) {
return input != null;
}
});

Surely the same is already possible with commons.



On Thu, Jul 4, 2013 at 12:23 PM, Dave Brosius **
wrote:

  This implies that having arrays with some null elements is

a) somewhat common
2) a good idea


I'd say both are not true.

I'm not sure the library should promote that the above is the case.



On 07/04/2013 02:43 PM, Rafael Santini wrote:

  Hi,

I would like to propose a method in ObjectUtils class that receives an
array of objects and returns true if all objects are not null. I have
implemented the following:

public static boolean isNull(Object object) {
return object == null;
}

public static boolean isNotNull(Object object) {
return isNull(object) == false;
}

public static boolean isNotNull(Object... objects) {
for (Object object : objects) {
if (isNull(object)) {
return false;
}
}
return true;
}

Can I submit a patch for this feature?

Thanks,

Rafael Santini




--**
--**-
To unsubscribe, e-mail: 
dev-unsubscribe@commons.**apac**he.org<http://apache.org>

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





--**
--**-
To unsubscribe, e-mail: 
dev-unsubscribe@commons.**apac**he.org<http://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





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

Re: Lang: ObjectUtils

[Dave Brosius]

This implies that having arrays with some null elements is

a) somewhat common
2) a good idea


I'd say both are not true.

I'm not sure the library should promote that the above is the case.



On 07/04/2013 02:43 PM, Rafael Santini wrote:

Hi,

I would like to propose a method in ObjectUtils class that receives an 
array of objects and returns true if all objects are not null. I have 
implemented the following:


public static boolean isNull(Object object) {
   return object == null;
}

public static boolean isNotNull(Object object) {
   return isNull(object) == false;
}

public static boolean isNotNull(Object... objects) {
   for (Object object : objects) {
   if (isNull(object)) {
   return false;
   }
   }
   return true;
}

Can I submit a patch for this feature?

Thanks,

Rafael Santini




-
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: [IO] converting streams to buffered versions - rename asBufferedxxxx to buffer?`

[Dave Brosius]

or ByteArrayInput/OutputStream

On 05/16/2013 01:13 PM, Jörg Schaible wrote:

sebb wrote:


The issue
https://issues.apache.org/jira/browse/IO-330

added 4 methods:
public static Buffered asBuffered(final  )
where  = InputStream, OutputStream, Reader, Writer

I just noticed that
https://issues.apache.org/jira/browse/IO-233
suggests overloaded methods called buffer instead:

public static Buffered buffer(final  )

This is quite a lot easier to type, so I propose to rename the methods
(and link the JIRAs) unless there are objections.

+1

However, I'd wrap the provided stream/reader/writer only, if it is not
already a (derived) buffered implementation.

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: [BCEL] 6.0 release

[Dave Brosius]

On 03/19/2012 10:18 AM, Honton, Charles wrote:

Any idea when BCEL 6.0 (with support for annotations) will be released?

Is there a maven repository available for the snapshot version?

Thanks,
Chas

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





The instruction INVOKE_DYNAMIC needs to be implemented yet, at a minimum.

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

Re: [VOTE][Lang] Update to Java 6

[Dave Brosius]

 +1  - Original Message -From: "Gary Gregory" 
>;ggreg...@apache.org;http://twitter.com/GaryGregory

Re: [codec]Bug or Feature

[Dave Brosius]

looks wrong to me as well.



On 02/11/2012 12:01 PM, Andreas Menke wrote:

Hi,

from BaseNCodec.java:

how does resizeBuffer() know how big 'int size' is? Bug or Feature?

/**
 * Ensure that the buffer has room for size bytes
 *
 * @param size minimum spare space required
 */
protected void ensureBufferSize(int size){
if ((buffer == null) || (buffer.length < pos + size)){
resizeBuffer();
}
}

Regards

Andreas




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

Re: [BCEL] Move to JIRA?

[Dave Brosius]

fine by me

On 11/25/2011 08:32 PM, sebb wrote:

BCEL currently uses Bugzilla, but AFAIK all other Commons components use JIRA

Should BCEL be moved to JIRA?

Just a thought.

-
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] API design

[Dave Brosius]

 +1altho, i'd think that
@CSVField(trim = true)

would often want to be applied at the class level, so many the name isn't so 
good

@CSVOptions ?  - Original Message -From: "Emmanuel Bourg" 
>;ebo...@apache.org

Re: [bcel] Backwards Incompatible Change to Visitor

[Dave Brosius]

Sebb is right... my mistake... apologies, and thanks for the fix.

dave

On 08/20/2011 09:15 PM, sebb wrote:

On 17 August 2011 07:06, Stefan Bodewig  wrote:

Hi,

with svn revision 1158060 the bcel.generic.Visitor interface has become
package private, breaking the Gump builds of Xalan XSLTC,
commons-javaflow and likely other downstream code.

Has this change been intentional?

I don't think so.

The rest of the commit just removes public from methods.

I assume that was a mistake to change the interface itself, as it does
not agree with the log message.

I've reverted the change of interface visibilty.


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





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

Re: [lang?] Converting an array to an Iterable

[Dave Brosius]

 What would this do that java.util.Arrays.asList does not?  - Original 
Message -From: "Oliver Heger" >;oliver.he...@oliver-heger.de

Re: [math] serialVersionUID

[Dave Brosius]

On 08/07/2011 12:17 PM, Luc Maisonobe wrote:


I use eclipse for this.

I like Jörg suggestion too but have one question: is there a problem 
if two different classes have the same id ? They will differ by fully 
qualified class name, of course, but is it sufficient ?


nothing wrong with two classes having the same serialVersionUID.

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

Re: [BCEL] Code format non-standard

[Dave Brosius]

 no objections(you'll find a bunch of tabs in there as well)  - Original 
Message -From: "sebb" >;seb...@gmail.com

Re: [BCEL] Move code to Commons SVN ?

[Dave Brosius]

hey.. wooops, no. :)

On 07/23/2011 04:56 AM, sebb wrote:

On 23 July 2011 04:45, Dave Brosius  wrote:

Thanks,

also, is the commit hook that sends email notifications for BCEL set up?

Yes, it is the standard commons one.


  Had some commits tonite, but didn't see emails.

They go to

comm...@commons.apache.org

Are you subscribed there?


dave


On 07/22/2011 07:35 AM, sebb wrote:

https://svn.apache.org/repos/asf/commons/proper/bcel

On 22 July 2011 12:21, Dave Brosiuswrote:

What's the svn url now?

On 07/22/2011 06:45 AM, Torsten Curdt wrote:

awesome ... thx!

On Fri, Jul 22, 2011 at 11:26 AM, Henri Yandell
  wrote:

Done.

http://svn.apache.org/repos/asf/commons/proper/bcel/

On Fri, Jul 22, 2011 at 1:55 AM, Torsten Curdt
  wrote:

+1

On Fri, Jul 22, 2011 at 10:53 AM, Jörg Schaible
  wrote:

sebb wrote:


The BCEL code is still under the jakarta SVN tree, which means that
commit messages go to a Jakarta mailing list.

Surely we should move the code to Commons now?

+1



-
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




-
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: [BCEL] Move code to Commons SVN ?

[Dave Brosius]

Thanks,

also, is the commit hook that sends email notifications for BCEL set up? 
Had some commits tonite, but didn't see emails.


dave


On 07/22/2011 07:35 AM, sebb wrote:

https://svn.apache.org/repos/asf/commons/proper/bcel

On 22 July 2011 12:21, Dave Brosius  wrote:

What's the svn url now?

On 07/22/2011 06:45 AM, Torsten Curdt wrote:

awesome ... thx!

On Fri, Jul 22, 2011 at 11:26 AM, Henri Yandell
  wrote:

Done.

http://svn.apache.org/repos/asf/commons/proper/bcel/

On Fri, Jul 22, 2011 at 1:55 AM, Torsten Curdtwrote:

+1

On Fri, Jul 22, 2011 at 10:53 AM, Jörg Schaible
wrote:

sebb wrote:


The BCEL code is still under the jakarta SVN tree, which means that
commit messages go to a Jakarta mailing list.

Surely we should move the code to Commons now?

+1



-
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





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

Re: [BCEL] Move code to Commons SVN ?

[Dave Brosius]

What's the svn url now?

On 07/22/2011 06:45 AM, Torsten Curdt wrote:

awesome ... thx!

On Fri, Jul 22, 2011 at 11:26 AM, Henri Yandell  wrote:

Done.

http://svn.apache.org/repos/asf/commons/proper/bcel/

On Fri, Jul 22, 2011 at 1:55 AM, Torsten Curdt  wrote:

+1

On Fri, Jul 22, 2011 at 10:53 AM, Jörg Schaible
  wrote:

sebb wrote:


The BCEL code is still under the jakarta SVN tree, which means that
commit messages go to a Jakarta mailing list.

Surely we should move the code to Commons now?

+1



-
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

BCEL: Code Review Please

[Dave Brosius]

Found an collection type error when adding generics in this code below.

Collection was holding both ElementValueGen and ElementValue objects 
which are unrelated by inheritance.


Modified code so only ElementValueGen are in the collection, using

-   evalues.add(datums[i]);
+   evalues.add(ElementValueGen.copy(datums[i], cpool, 
true));



Do you folks agree this is the correct change?

 Original Message 
Subject: 	svn commit: r1149461 - 
/jakarta/bcel/trunk/src/main/java/org/apache/bcel/generic/ArrayElementValueGen.java 


Date:   Fri, 22 Jul 2011 04:41:57 -
From:   dbros...@apache.org
Reply-To:   d...@jakarta.apache.org
To: notificati...@jakarta.apache.org



Author: dbrosius
Date: Fri Jul 22 04:41:56 2011
New Revision: 1149461

URL: http://svn.apache.org/viewvc?rev=1149461&view=rev
Log:
fix bad collection element type (ElementValueGen vs ElementValue) exposed by 
adding generics

Modified:

jakarta/bcel/trunk/src/main/java/org/apache/bcel/generic/ArrayElementValueGen.java

Modified: 
jakarta/bcel/trunk/src/main/java/org/apache/bcel/generic/ArrayElementValueGen.java
URL: 
http://svn.apache.org/viewvc/jakarta/bcel/trunk/src/main/java/org/apache/bcel/generic/ArrayElementValueGen.java?rev=1149461&r1=1149460&r2=1149461&view=diff
==
--- 
jakarta/bcel/trunk/src/main/java/org/apache/bcel/generic/ArrayElementValueGen.java
 (original)
+++ 
jakarta/bcel/trunk/src/main/java/org/apache/bcel/generic/ArrayElementValueGen.java
 Fri Jul 22 04:41:56 2011
@@ -22,6 +22,7 @@ import java.io.IOException;
 import java.util.ArrayList;
 import java.util.Iterator;
 import java.util.List;
+
 import org.apache.bcel.classfile.ArrayElementValue;
 import org.apache.bcel.classfile.ElementValue;

@@ -29,12 +30,12 @@ public class ArrayElementValueGen extend
 {
// J5TODO: Should we make this an array or a list? A list would be 
easier to
// modify ...
-   private List /* ElementValueGen */evalues;
+   private List  evalues;

public ArrayElementValueGen(ConstantPoolGen cp)
{
super(ARRAY, cp);
-   evalues = new ArrayList();
+   evalues = new ArrayList();
}

public ArrayElementValueGen(int type, ElementValue[] datums,
@@ -44,10 +45,10 @@ public class ArrayElementValueGen extend
if (type != ARRAY)
throw new RuntimeException(
"Only element values of type array can be 
built with this ctor - type specified: " + type);
-   this.evalues = new ArrayList();
+   this.evalues = new ArrayList();
for (int i = 0; i<  datums.length; i++)
{
-   evalues.add(datums[i]);
+   evalues.add(ElementValueGen.copy(datums[i], cpool, 
true));
}
}

@@ -58,9 +59,9 @@ public class ArrayElementValueGen extend
{
ElementValue[] immutableData = new ElementValue[evalues.size()];
int i = 0;
-   for (Iterator iter = evalues.iterator(); iter.hasNext();)
+   for (Iterator  iter = evalues.iterator(); 
iter.hasNext();)
{
-   ElementValueGen element = (ElementValueGen) iter.next();
+   ElementValueGen element = iter.next();
immutableData[i++] = element.getElementValue();
}
return new ArrayElementValue(type, immutableData, cpGen
@@ -75,7 +76,7 @@ public class ArrayElementValueGen extend
boolean copyPoolEntries)
{
super(ARRAY, cpool);
-   evalues = new ArrayList();
+   evalues = new ArrayList();
ElementValue[] in = value.getElementValuesArray();
for (int i = 0; i<  in.length; i++)
{
@@ -87,9 +88,9 @@ public class ArrayElementValueGen extend
{
dos.writeByte(type); // u1 type of value (ARRAY == '[')
dos.writeShort(evalues.size());
-   for (Iterator iter = evalues.iterator(); iter.hasNext();)
+   for (Iterator  iter = evalues.iterator(); 
iter.hasNext();)
{
-   ElementValueGen element = (ElementValueGen) iter.next();
+   ElementValueGen element = iter.next();
element.dump(dos);
}
}
@@ -98,9 +99,9 @@ public class ArrayElementValueGen extend
{
StringBuffer sb = new StringBuffer();
sb.append("[");
-   for (Iterator iter = evalues.iterator(); iter.hasNext();)
+   for (Iterator  iter = evalues.iterator(); 
iter.hasNext();)
{
-   ElementValueGen element = (ElementValueGen) iter.next();
+  

Re: [BCEL] Next release

[Dave Brosius]

On 07/19/2011 05:03 AM, Torsten Curdt wrote:

+1 for using 1.5

So then let's call it 6.0? ...and work through bugzilla towards a release?



I agree with naming it 6.0. Another more important reason is that this 
version of bcel is backwards incompatible with previous releases, in 
this regard:


In previous releases, if client code wanted to process annotations, when 
processing attributes had to look for ATTR_UNKNOWN, and once received 
look at the attribute type byte and see if it matches the constants for 
the various annotation values. Now with this version, you will not 
receive the constant ATTR_UNKNOWN for annotations, but instead get the 
first class annotation constant itself. Therefore code will break 
because they will never process these annotations.




cheers,
Torsten

-
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: [BCEL] Next release

[Dave Brosius]

If we can agree that BCEL will have a minimum requirement of 1.5 for the 
next version, then we should probably actually use 1.5 throughout on 
purpose, rather than by accident. I'd be happy to participate in making 
these changes. Can we vote on that part of it at least, so that work 
could start?


[ ] +1, agreed
[ ] +0, ok, but don't care
[ ] -1, don't agree, with reason


On 07/18/2011 12:56 PM, Torsten Curdt wrote:

I'm all for it.

I say what I've said all this time when questions like this came up.
We need testers! There has been quite few changes. Just releasing
without some people spending some time ...or telling us "yes, trunk
works for me!" I am still not comfortable with.


But there needs to be a decision which seems clear cut to me. There is code in 
the code base (by accident--i suppose) now that requires 1.5. Previously we 
didn't have that requirement, so pushing out a release means raising the 
minimum to 1.5. My vote is lets do it two both. But everyone should be clear 
about this decision. Do we call it BCEL 6 because of this?

Actually that might help with the above changes, too.

+1 for calling it 6.0

...and if we get at least 3 people saying "yes, trunk works for me you
also get my +1 for a release.
Although there still might be some work in bugzilla that has
accumulated over time.

cheers,
Torsten




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

Re: [BCEL] Next release

[Dave Brosius]

I'm all for it. But there needs to be a decision which seems clear cut to me. 
There is code in the code base (by accident--i suppose) now that requires 1.5. 
Previously we didn't have that requirement, so pushing out a release means 
raising the minimum to 1.5. My vote is lets do it two both. But everyone should 
be clear about this decision. Do we call it BCEL 6 because of this?dave   - 
Original Message -From: "Martin von Gagern" 
>;mar...@von-gagern.net

Re: [VOTE] Release Apache Commons Digester 3.0 based on RC1 - take2

[Dave Brosius]

 Perhaps i am confused but it appears the source code links on the web site 
(http://commons.apache.org/digester/source-repository.html) are 
wrong,http://svn.apache.org/viewvc/commons/sandbox/digester3/trunk 
svn checkout http://svn.apache.org/repos/asf/commons/sandbox/digester3/trunk 
commons-digester3 Is this the right one -- it seems to worksvn checkout 
http://svn.apache.org/repos/asf/commons/proper/digester/trunk 
commons-digesterCould someone fix them, (or me, which ever is wrong?)dave  
- Original Message -From: "Simone Tripodi" 
>;simonetrip...@apache.org