RE: US Export classification & ECCN registration for encryption in commons?

[Chen, Haifeng]

Thanks Benedikt and Stian for the instructions!
Will do that.

Regards,
Haifeng


-Original Message-
From: Stian Soiland-Reyes [mailto:st...@apache.org] 
Sent: Saturday, June 4, 2016 6:52 PM
To: Commons Developers List 
Subject: Re: US Export classification & ECCN registration for encryption in 
commons?

If you are ready to do the Crypto release now, then let's just prepare that 
ECCN registration email for Commons Crypto alone, no need to wait.

We should send it before we post a Release Candidate of Crypto (In theory 
before we submit the code to git! ;-/). I'll send it now.
On 4 Jun 2016 11:35 a.m., "Benedikt Ritter"  wrote:

> Chen, Haifeng  schrieb am Fr., 3. Juni 2016 um
> 08:20 Uhr:
>
> > Thanks Stian, Dapeng and folks!
> >
> > For Commons Crypto, do we still have to wait for other process to 
> > finish or we now can go forward with the first release process?
> >
>
> I don't see any other blockers.
>
> Benedikt
>
>
> >
> > Regards,
> > Haifeng
> >
> > -Original Message-
> > From: Stian Soiland-Reyes [mailto:st...@apache.org]
> > Sent: Thursday, June 2, 2016 10:36 PM
> > To: Commons Developers List 
> > Subject: Re: US Export classification & ECCN registration for 
> > encryption in commons?
> >
> > Thanks! It's already on https://www.apache.org/licenses/exports/
> >
> > I've added to the Commons Crypto README:
> >
> > https://github.com/apache/commons-crypto#export-restrictions
> >
> > (if changing, modify this text in pom.xml  and 
> > regenerate
> > README.md)
> >
> >
> > Shall I add VFS2 as well? Then Gary can send a joint notification
> message.
> >
> >
> >
> >
> > On 1 June 2016 at 03:01, Sun, Dapeng  wrote:
> > > Thank Stian for your review!
> > >
> > >>We also need a second  for the (future) source/binary
> > distributions with ControlledSource href= 
> > https://www.apache.org/dist/commons/crypto/ - you would need to
> duplicate
> > the OpenSSL and JavaSE  for that. See other 
> > examples in the XML file.
> > > Thank you for pointing it out, we should add it.
> > >
> > >> is it 1.0.0 we're targeting for the first Commons Crypto release?
> > > Yes, 1.0.0 would be the first release.
> > >
> > > I have updated the staging website.
> > > http://www.staging.apache.org/licenses/exports/index.html
> > >
> > >
> > > Regards
> > > Dapeng
> > >
> > > -Original Message-
> > > From: Stian Soiland-Reyes [mailto:st...@apache.org]
> > > Sent: Tuesday, May 31, 2016 6:45 PM
> > > To: Commons Developers List
> > > Subject: Re: US Export classification & ECCN registration for
> encryption
> > in commons?
> > >
> > > Thanks! Looks good.
> > >
> > > We also need a second  for the (future) source/binary
> > distributions with ControlledSource href= 
> > https://www.apache.org/dist/commons/crypto/ - you would need to
> duplicate
> > the OpenSSL and JavaSE  for that. See other 
> > examples in the XML file.
> > >
> > > In the second Version you can say 1.0.0 and later - 
> > > is
> it
> > 1.0.0 we're targeting for the first Commons Crypto release?
> > >
> > > On 31 May 2016 at 11:03, Sun, Dapeng  wrote:
> > >> Thank Stian and Haifeng, I have updated the file at my cms workspace.
> > >> If the change is okay for you, I will try to commit it to 
> > >> http://www.staging.apache.org/licenses/exports/
> > >>
> > >> Index: trunk/content/licenses/exports/index.page/eccnmatrix.xml
> > >> =
> > >> ==
> > >> --- trunk/content/licenses/exports/index.page/eccnmatrix.xml
> > (revision 1655892)
> > >> +++ trunk/content/licenses/exports/index.page/eccnmatrix.xml
> > (working copy)
> > >> @@ -212,6 +212,25 @@
> > >>  
> > >>
> > >>
> > >> +Apache Commons Crypto
> > >> +
> > >> +  development
> > >> +  5D002
> > >> +  https://git-wip-us.apache.org/repos/asf/commons-crypto.git";>
> > >> +ASF
> > >> +designed for use with encryption library
> > >> +  
> > >> +  http://www.openssl.org/source/";>
> > >> +The OpenSSL Project
> > >> +general-purpose cryptography library included with
> > OpenSSL
> > >> +  
> > >> +  http://www.oracle.com/technetwork/java/javase/downloads/index.html";>
> > >> +Oracle
> > >> +general-purpose cryptography library (JCE) included 
> > >> + with
> > Java
> > >> +  
> > >> +
> > >> +  
> > >> +  
> > >>  Apache Commons OpenPGP
> > >>  
> > >>development
> > >>
> > >>
> > >> Regards
> > >> Dapeng
> > >>
> > >> -Original Message-
> > >> From: Stian Soiland-Reyes [mailto:st...@apache.org]
> > >> Sent: Monday, May 30, 2016 5:20 PM
> > >> To: Commons Developers List
> > >> Subject: RE: US Export classification & ECCN registration for
> > encryption in commons?
> > >>
> > >> I think we are good to continue as a "normal" 5D002
> self-classification.
> > >>
> > >> Great if you will have a go, let me know if you would like me to 
> > >> help
> > or review!
> > >>
> > >> See http://www.apache.org/dev/cryp

[Math] Commons Math (r)evolution

[Gilles]

Hello.

Commons Math as it was in the last official release (v3.6.1) and
consequently as it is in the current development branch has
become unmaintainable.

This conclusion is unavoidable when looking at the following:
 1. codebase statistics (as of today):
* src/main/java   90834 lines of Java code (882 files)
* src/test/java   95595 lines of Java code (552 files)
* src/userguide/java   3493 lines of Java code (19 files)
 2. number of posts on the "dev" ML (related to [Math]) in the
last 2 months:
* Gilles74
* Artem Barger  20
* sebb  15
* Rob Tompkins   9
* Eric Barnhill  7
* 19 other people   46
 3. development/maintenance activity in the last 4 months:
* commits by Gilles  133
* commits by others   12

According to JIRA, among 180 issues currently targeted for the
next major release (v4.0), 139 have been resolved (75 of which
were not in v3.6.1).

So, on the one hand, a lot of work has been done already, but
on the other, a lot remains.
Some issues have been pending for several years, in particular
those that required a major refactoring (e.g. in the packages
"o.a.c.m.linear" and "o.a.c.m.optim").

The remaining work is unlikely to be completed soon since the
fork of Commons Math has drastically reduced the development
capacity.

Moreover, as whole areas of the codebase have become in effect
unsupported, it would be deceiving to release a version 4.0 of
Commons Math that would include all of it.

Of course, anyone who wishes to maintain some of these codes
(answer user questions, fix bugs, create enhancements, etc.)
is most welcome to step forward.

But I'm not optimistic that the necessary level of support can
be achieved in the near future for all the codebase.
Waiting for that to happen would entail that code that could
be in a releasable state soon will be on hold for an indefinite
time.

The purpose of this post is to initiate a discussion about
splitting Commons Math, along the following lines:
1. Identify independent functionality that can be maintained
   even by a small (even a 1-person) team within Commons and
   make it a new component.
2. Identify functionality that cannot be maintained anymore
   inside Commons and try to reach out to users of this
   functionality, asking whether they would be willing to
   give a helping hand.
   If there is sufficient interest, and a new development
   team can form, that code would then be transferred to the
   Apache "incubator".

There are numerous advantages to having separate components
rather than a monolithic library:
 * Limited and well-defined scope
 * Immediate visibility of purpose
 * Lower barrier to entry
 * Independent development policy
 * Homogeneous codebase
 * Independent release schedule
 * Foster a new community around the component

According to the most recent development activity, the likely
candidates for becoming a new component are:
 * Pseudo-random numbers generators (package "o.a.c.m.rng")
 * Complex numbers (package "o.a.c.m.complex")
 * Clustering algorithms (package "o.a.c.m.ml.clustering")

Other potential candidates:
 * "FastMath" (which should be renamed to something like
   "AccurateMath", cf. reports about slowness of some of
   the functions)
 * Special functions (package "o.a.c.m.special")
 * Selected "utilities" (package "o.a.c.m.util")


Best regards,
Gilles


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

TSU NOTIFICATION - Encryption

[Gary Gregory]

SUBMISSION TYPE:  TSU
SUBMITTED BY: Gary Gregory
SUBMITTED FOR:Apache Software Foundation
POINT OF CONTACT: Secretary, Apache Software Foundation
EMAIL:secret...@apache.org
FAX:  +1-919-573-9199

MANUFACTURER(S):

The Apache Software Foundation
Oracle
The OpenSSL Project


PRODUCT NAME/MODEL #: Apache Commons Crypto
ECCN: 5D002


NOTIFICATION:

This email is notification of publicly available encryption software.

To the best of our knowledge this software is covered under EAR Part
740.13(e)(3).

Detailed information about the software including source code and a list of
dependencies can be found at http://www.apache.org/licenses/exports/

Gary Gregory
Chair of the Apache Commons Project Management Committee.

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

Re: [ALL] About binary compatibility

[Ralph Goers]

I think we should adopt Java 9’s multi-release jars [1] as standard practice.  
While this won’t let us update our APIs without breaking compatibility (which 
may still be necessary), it will allow us to leverage some features in newer 
versions of Java without worrying about breaking backward compatibility.  

I also see no reason we can’t leave links on the web site to the last release 
that supported an older version of Java and have a branch for further work if 
anyone wants to do it.  

In the end I think we have to have an approach where we can move forward and 
support the newer versions of Java more quickly while still continuing to be 
able to support older versions - if we choose to.

As far as moving forward and breaking binary compatibility, I believe Oliver 
did a great job with Configuration 2.0.  He first worked on an experimental 
branch and got it to the state where he could release it.  Although I wish I 
could have contributed more to his efforts I think the way he went about it 
encouraged others to review what he was doing and participate if and when they 
wanted to.  At the same time bugs in the older releases continued to be 
addressed.

Ralph

[1] http://openjdk.java.net/jeps/238 
> On Jun 5, 2016, at 7:46 AM, Oliver Heger  wrote:
> 
> Hi Benedikt,
> 
> Am 02.06.2016 um 22:42 schrieb Benedikt Ritter:
>> Hi,
>> 
>> we do seem to have different opinions when it comes to binary compatibility
>> and how it should be handled. Usually we would say "this should be decided
>> on a component basis". However this discussion is coming up again and again
>> and I think we should try the impossible and agree on something that we can
>> document.
>> 
>> So here is my view on the topic:
>> 
>> - since our components are depended upon by a lot of projects, we need to
>> take special care regarding compatibility.
>> - we must not break BC in a release that could collide with an earlier
>> version. In other words, when we break BC, we have to change package and
>> maven coordinates.
>> - BUT since we're all doing this on our spare time, there is no need to
>> hold on old APIs just for the sake of it. For this reason, BC may be broken
>> any time, if the steps above a followed and it has been discussed on the
>> ML. Fixes can always be backported to old releases, by people who need it.
>> - If there are committers who are willing to work on old version and
>> committers who want to work on API redesigns, we can branch and work in
>> paralell.
>> - Changing the Java Language requirement does not break BC and can
>> therefore be done without pumping the major version.
>> 
>> What is your view on the topic?
> 
> these points are rather technical ones, and most of us will probably
> agree. The more important question is IMHO: when do we explicitly break
> BC because we want to make use of new language features or switch to a
> different design? In this area we used to be very conservative.
> 
> Take BCEL as an example. There was a strong momentum about half a year
> or so ago to push out a new major release breaking BC. Then discussion
> started to revert breaking changes. This would of course have been the
> ideal solution for all users: getting a new version without migration
> effort. However, the result was that work on reverting changes started,
> but was never finished. The momentum vanished, and the release is still
> overdue. So would it has been better to break BC in this case? I tend to
> say yes.
> 
> Or let's discuss another component: [lang]. The last major release
> happened about 5 years ago. In software business these are ages. So
> would it make sense to start working on a new version focusing on Java 8
> and better support for Lambdas? We could at least start something in an
> experimental branch or the sandbox to experiment with new functionality.
> But it is obviously not our style to do this.
> 
> It is certainly difficult to find the right balance between stability
> and innovation. For our fundamental components it is for sure no good
> idea to push out an incompatible major release every few months. But
> every 3 or 4 years when there are significant changes in the Java
> ecosystem would probably be okay.
> 
> My $0.02
> Oliver
> 
>> 
>> Benedikt
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 

Re: [ALL] About binary compatibility

[Jochen Wiedmann]

On Sun, Jun 5, 2016 at 4:46 PM, Oliver Heger
 wrote:

> Take BCEL as an example. There was a strong momentum about half a year
> or so ago to push out a new major release breaking BC. Then discussion
> started to revert breaking changes. This would of course have been the
> ideal solution for all users: getting a new version without migration
> effort. However, the result was that work on reverting changes started,
> but was never finished. The momentum vanished, and the release is still
> overdue. So would it has been better to break BC in this case? I tend to
> say yes.

I don't think that example is very helpful. At least, I don't know how
anyone should have foreseen the outcome.

> Or let's discuss another component: [lang]. The last major release
> happened about 5 years ago. In software business these are ages. So
> would it make sense to start working on a new version focusing on Java 8
> and better support for Lambdas? We could at least start something in an
> experimental branch or the sandbox to experiment with new functionality.
> But it is obviously not our style to do this.

In that case, i'd strongly be in favour of a new release branch (no
need for sandbox) with all the incompatible changes, and a release out
of that branch. As long, as the old branch remains available for minor
maintenance issues.

Jochen

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

Re: [ALL] About binary compatibility

[James Carman]

Not quite. OSGi is a special case. It's much more restrictive than simple
J2SE, because it can be. In the general case, the public API for OSGi is
different from the public API for J2SE. Let's not confuse the two.

On Sun, Jun 5, 2016 at 2:30 PM Gary Gregory  wrote:

> On Jun 5, 2016 11:12 AM, "sebb"  wrote:
> >
> > On 5 June 2016 at 18:51, Thomas Vandahl  wrote:
> > > On 03.06.16 10:38, sebb wrote:
> > >> On 2 June 2016 at 21:42, Benedikt Ritter  wrote:
> > >>> - we must not break BC in a release that could collide with an
> earlier
> > >>> version. In other words, when we break BC, we have to change package
> and
> > >>> maven coordinates.
> > >>
> > >> +1, with the proviso that we must not break BC in the *public* API.
> > >> Unfortunately it is not always clear what is public.
> > >>
> > >
> > > All commons components are released with OSGi bundle metadata, where
> the
> > > packages for a public API can be stated. If this information is
> > > maintained correctly, everyone should be able to tell public from
> > > private API changes.
> >
> > The problem is determining what is supposed to be public, not documenting
> it.
>
> We could document OSGi as how we spec public APIs.
>
> Gary
>
> >
> > Though I would question whether non-OSGi users would think to look at
> > the metadata.
> >
> > > Bye, Thomas.
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>

Re: [ALL] About binary compatibility

[Gary Gregory]

On Jun 5, 2016 11:12 AM, "sebb"  wrote:
>
> On 5 June 2016 at 18:51, Thomas Vandahl  wrote:
> > On 03.06.16 10:38, sebb wrote:
> >> On 2 June 2016 at 21:42, Benedikt Ritter  wrote:
> >>> - we must not break BC in a release that could collide with an earlier
> >>> version. In other words, when we break BC, we have to change package
and
> >>> maven coordinates.
> >>
> >> +1, with the proviso that we must not break BC in the *public* API.
> >> Unfortunately it is not always clear what is public.
> >>
> >
> > All commons components are released with OSGi bundle metadata, where the
> > packages for a public API can be stated. If this information is
> > maintained correctly, everyone should be able to tell public from
> > private API changes.
>
> The problem is determining what is supposed to be public, not documenting
it.

We could document OSGi as how we spec public APIs.

Gary

>
> Though I would question whether non-OSGi users would think to look at
> the metadata.
>
> > Bye, Thomas.
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

Re: [ALL] About binary compatibility

[sebb]

On 5 June 2016 at 18:51, Thomas Vandahl  wrote:
> On 03.06.16 10:38, sebb wrote:
>> On 2 June 2016 at 21:42, Benedikt Ritter  wrote:
>>> - we must not break BC in a release that could collide with an earlier
>>> version. In other words, when we break BC, we have to change package and
>>> maven coordinates.
>>
>> +1, with the proviso that we must not break BC in the *public* API.
>> Unfortunately it is not always clear what is public.
>>
>
> All commons components are released with OSGi bundle metadata, where the
> packages for a public API can be stated. If this information is
> maintained correctly, everyone should be able to tell public from
> private API changes.

The problem is determining what is supposed to be public, not documenting it.

Though I would question whether non-OSGi users would think to look at
the metadata.

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

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

Re: [ALL] About binary compatibility

[Thomas Vandahl]

On 03.06.16 10:38, sebb wrote:
> On 2 June 2016 at 21:42, Benedikt Ritter  wrote:
>> - we must not break BC in a release that could collide with an earlier
>> version. In other words, when we break BC, we have to change package and
>> maven coordinates.
> 
> +1, with the proviso that we must not break BC in the *public* API.
> Unfortunately it is not always clear what is public.
> 

All commons components are released with OSGi bundle metadata, where the
packages for a public API can be stated. If this information is
maintained correctly, everyone should be able to tell public from
private API changes.

Bye, Thomas.



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

Re: [LANG] Ready for 3.5?

[Pascal Schumacher]

Another thing that has to be resolved before a release. When I run "mvn 
clirr:check", clirr reports errors for these classes:

org.apache.commons.lang3.time.DateParser
org.apache.commons.lang3.time.DatePrinter
org.apache.commons.lang3.time.FastDatePrinter

I would have pasted them, but it shows me german error messages. :(

Am 02.06.2016 um 23:18 schrieb Pascal Schumacher:
should be "If somebody else would like to RM, I'm also very happy with 
that."


Sorry,
Pascal

Am 02.06.2016 um 23:14 schrieb Pascal Schumacher:

Hello Benedikt

guess a 3.5 is overdue as 3.4 was released over a year ago. There are 
88 fixed jira issues:


https://issues.apache.org/jira/issues/?jql=project%20%3D%20LANG%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%203.5%20ORDER%20BY%20priority%20DESC 



With your help I am willing to give RMing a try. :) Of course I 
somebody else would like to do I'm also very happy with that. :)


I think LANG-1229: "Performance regression due to cyclic hashCode 
guard" should be solved before a release. This issue has been caused 
by the fix for https://issues.apache.org/jira/browse/LANG-456 
"HashCodeBuilder throws StackOverflowError in bidirectional navigable 
association". The suggested solution at 
https://issues.apache.org/jira/browse/LANG-1229 is to add a new 
method to HashCodeBuilder which allows appending with a cycle check. 
Any input on how to name this method or other solutions for this is 
very welcome. (Of course if no good solution is found we can always 
reopen LANG-456, as it not been released.)


Thanks,
Pascal

Am 02.06.2016 um 22:48 schrieb Benedikt Ritter:

Hello Pascal,

you have been working through the issues of [LANG] recently. Would 
you like
to do RM for 3.5? I can help you with that. I've done it several 
times in

the past.

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: [all] Javadoc

[Stian Soiland-Reyes]

I think a mere indirection page could do, but see many potential
maintenance issues with updating a single Javadoc folder across Commons
components.

Perhaps we can provide a common XML for Javadoc external references or
there is a Javadoc aggregation tool we could use?
On 5 Jun 2016 4:24 a.m., "Gary Gregory"  wrote:

> I think it would be nice to have a link to a Javadoc site for ALL
> components in one lump.
>
> This would go on the main page.
>
> Thoughts?
>
> Gary
>
> --
> 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
>

Re: [ALL] About binary compatibility

[sebb]

In the case of BCEL, the coding actually stalled on fixing some bugs
which were proving both difficult to test and fix.

The code that was reverted to become BC was largely orthogonal to that.



On 5 June 2016 at 16:58, Benedikt Ritter  wrote:
> Hello Oilver,
>
> Oliver Heger  schrieb am So., 5. Juni 2016 um
> 16:46 Uhr:
>
>> Hi Benedikt,
>>
>> Am 02.06.2016 um 22:42 schrieb Benedikt Ritter:
>> > Hi,
>> >
>> > we do seem to have different opinions when it comes to binary
>> compatibility
>> > and how it should be handled. Usually we would say "this should be
>> decided
>> > on a component basis". However this discussion is coming up again and
>> again
>> > and I think we should try the impossible and agree on something that we
>> can
>> > document.
>> >
>> > So here is my view on the topic:
>> >
>> > - since our components are depended upon by a lot of projects, we need to
>> > take special care regarding compatibility.
>> > - we must not break BC in a release that could collide with an earlier
>> > version. In other words, when we break BC, we have to change package and
>> > maven coordinates.
>> > - BUT since we're all doing this on our spare time, there is no need to
>> > hold on old APIs just for the sake of it. For this reason, BC may be
>> broken
>> > any time, if the steps above a followed and it has been discussed on the
>> > ML. Fixes can always be backported to old releases, by people who need
>> it.
>> > - If there are committers who are willing to work on old version and
>> > committers who want to work on API redesigns, we can branch and work in
>> > paralell.
>> > - Changing the Java Language requirement does not break BC and can
>> > therefore be done without pumping the major version.
>> >
>> > What is your view on the topic?
>>
>> these points are rather technical ones, and most of us will probably
>> agree. The more important question is IMHO: when do we explicitly break
>> BC because we want to make use of new language features or switch to a
>> different design? In this area we used to be very conservative.
>>
>
> Nevertheless I think we should document this. I'm tired of "why can't we
> implement this in a Java 6 compatible way" arguments. Java 6 is dead and
> Java 7 soon will be. There is no reason for us to support Java versions
> which not even Oracle supports anymore.
>
>
>>
>> Take BCEL as an example. There was a strong momentum about half a year
>> or so ago to push out a new major release breaking BC. Then discussion
>> started to revert breaking changes. This would of course have been the
>> ideal solution for all users: getting a new version without migration
>> effort. However, the result was that work on reverting changes started,
>> but was never finished. The momentum vanished, and the release is still
>> overdue. So would it has been better to break BC in this case? I tend to
>> say yes.
>>
>
> I agree with you on this.
>
>
>>
>> Or let's discuss another component: [lang]. The last major release
>> happened about 5 years ago. In software business these are ages. So
>> would it make sense to start working on a new version focusing on Java 8
>> and better support for Lambdas? We could at least start something in an
>> experimental branch or the sandbox to experiment with new functionality.
>> But it is obviously not our style to do this.
>>
>
> We have done this in the past for BeanUtils2 in the sandbox. I don't think
> experiments should be forked into the sandbox. My feeling is, that those
> experiments get less attention.
>
> Speaking about [lang]: I discussed a redesign with Henri a year ago. The
> only problem I see is the time constraint. [lang] is a pretty large code
> base (~29k LoC) and I fear the that I won't be able the bring the redesign
> to an end. If others like to push that, I'm all for that.
>
>
>>
>> It is certainly difficult to find the right balance between stability
>> and innovation. For our fundamental components it is for sure no good
>> idea to push out an incompatible major release every few months. But
>> every 3 or 4 years when there are significant changes in the Java
>> ecosystem would probably be okay.
>>
>
> Again I agree.
>
> Thank you,
> Benedikt
>
>
>>
>> My $0.02
>> Oliver
>>
>> >
>> > 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: [LANG] Ready for 3.5?

[Benedikt Ritter]

Hello Pascal,

I'd like to have more people who are able to RM for our components. How
about we make an appointment and then do a Hangout/Skype call and I give
you a walk through?

Benedikt

Pascal Schumacher  schrieb am Do., 2. Juni 2016
um 23:19 Uhr:

> should be "If somebody else would like to RM, I'm also very happy with
> that."
>
> Sorry,
> Pascal
>
> Am 02.06.2016 um 23:14 schrieb Pascal Schumacher:
> > Hello Benedikt
> >
> > guess a 3.5 is overdue as 3.4 was released over a year ago. There are
> > 88 fixed jira issues:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20LANG%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%203.5%20ORDER%20BY%20priority%20DESC
> >
> >
> > With your help I am willing to give RMing a try. :) Of course I
> > somebody else would like to do I'm also very happy with that. :)
> >
> > I think LANG-1229: "Performance regression due to cyclic hashCode
> > guard" should be solved before a release. This issue has been caused
> > by the fix for https://issues.apache.org/jira/browse/LANG-456
> > "HashCodeBuilder throws StackOverflowError in bidirectional navigable
> > association". The suggested solution at
> > https://issues.apache.org/jira/browse/LANG-1229 is to add a new method
> > to HashCodeBuilder which allows appending with a cycle check. Any
> > input on how to name this method or other solutions for this is very
> > welcome. (Of course if no good solution is found we can always reopen
> > LANG-456, as it not been released.)
> >
> > Thanks,
> > Pascal
> >
> > Am 02.06.2016 um 22:48 schrieb Benedikt Ritter:
> >> Hello Pascal,
> >>
> >> you have been working through the issues of [LANG] recently. Would
> >> you like
> >> to do RM for 3.5? I can help you with that. I've done it several
> >> times in
> >> the past.
> >>
> >> 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] About binary compatibility

[Benedikt Ritter]

Hello Oilver,

Oliver Heger  schrieb am So., 5. Juni 2016 um
16:46 Uhr:

> Hi Benedikt,
>
> Am 02.06.2016 um 22:42 schrieb Benedikt Ritter:
> > Hi,
> >
> > we do seem to have different opinions when it comes to binary
> compatibility
> > and how it should be handled. Usually we would say "this should be
> decided
> > on a component basis". However this discussion is coming up again and
> again
> > and I think we should try the impossible and agree on something that we
> can
> > document.
> >
> > So here is my view on the topic:
> >
> > - since our components are depended upon by a lot of projects, we need to
> > take special care regarding compatibility.
> > - we must not break BC in a release that could collide with an earlier
> > version. In other words, when we break BC, we have to change package and
> > maven coordinates.
> > - BUT since we're all doing this on our spare time, there is no need to
> > hold on old APIs just for the sake of it. For this reason, BC may be
> broken
> > any time, if the steps above a followed and it has been discussed on the
> > ML. Fixes can always be backported to old releases, by people who need
> it.
> > - If there are committers who are willing to work on old version and
> > committers who want to work on API redesigns, we can branch and work in
> > paralell.
> > - Changing the Java Language requirement does not break BC and can
> > therefore be done without pumping the major version.
> >
> > What is your view on the topic?
>
> these points are rather technical ones, and most of us will probably
> agree. The more important question is IMHO: when do we explicitly break
> BC because we want to make use of new language features or switch to a
> different design? In this area we used to be very conservative.
>

Nevertheless I think we should document this. I'm tired of "why can't we
implement this in a Java 6 compatible way" arguments. Java 6 is dead and
Java 7 soon will be. There is no reason for us to support Java versions
which not even Oracle supports anymore.


>
> Take BCEL as an example. There was a strong momentum about half a year
> or so ago to push out a new major release breaking BC. Then discussion
> started to revert breaking changes. This would of course have been the
> ideal solution for all users: getting a new version without migration
> effort. However, the result was that work on reverting changes started,
> but was never finished. The momentum vanished, and the release is still
> overdue. So would it has been better to break BC in this case? I tend to
> say yes.
>

I agree with you on this.


>
> Or let's discuss another component: [lang]. The last major release
> happened about 5 years ago. In software business these are ages. So
> would it make sense to start working on a new version focusing on Java 8
> and better support for Lambdas? We could at least start something in an
> experimental branch or the sandbox to experiment with new functionality.
> But it is obviously not our style to do this.
>

We have done this in the past for BeanUtils2 in the sandbox. I don't think
experiments should be forked into the sandbox. My feeling is, that those
experiments get less attention.

Speaking about [lang]: I discussed a redesign with Henri a year ago. The
only problem I see is the time constraint. [lang] is a pretty large code
base (~29k LoC) and I fear the that I won't be able the bring the redesign
to an end. If others like to push that, I'm all for that.


>
> It is certainly difficult to find the right balance between stability
> and innovation. For our fundamental components it is for sure no good
> idea to push out an incompatible major release every few months. But
> every 3 or 4 years when there are significant changes in the Java
> ecosystem would probably be okay.
>

Again I agree.

Thank you,
Benedikt


>
> My $0.02
> Oliver
>
> >
> > Benedikt
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] About binary compatibility

[Oliver Heger]

Hi Benedikt,

Am 02.06.2016 um 22:42 schrieb Benedikt Ritter:
> Hi,
> 
> we do seem to have different opinions when it comes to binary compatibility
> and how it should be handled. Usually we would say "this should be decided
> on a component basis". However this discussion is coming up again and again
> and I think we should try the impossible and agree on something that we can
> document.
> 
> So here is my view on the topic:
> 
> - since our components are depended upon by a lot of projects, we need to
> take special care regarding compatibility.
> - we must not break BC in a release that could collide with an earlier
> version. In other words, when we break BC, we have to change package and
> maven coordinates.
> - BUT since we're all doing this on our spare time, there is no need to
> hold on old APIs just for the sake of it. For this reason, BC may be broken
> any time, if the steps above a followed and it has been discussed on the
> ML. Fixes can always be backported to old releases, by people who need it.
> - If there are committers who are willing to work on old version and
> committers who want to work on API redesigns, we can branch and work in
> paralell.
> - Changing the Java Language requirement does not break BC and can
> therefore be done without pumping the major version.
> 
> What is your view on the topic?

these points are rather technical ones, and most of us will probably
agree. The more important question is IMHO: when do we explicitly break
BC because we want to make use of new language features or switch to a
different design? In this area we used to be very conservative.

Take BCEL as an example. There was a strong momentum about half a year
or so ago to push out a new major release breaking BC. Then discussion
started to revert breaking changes. This would of course have been the
ideal solution for all users: getting a new version without migration
effort. However, the result was that work on reverting changes started,
but was never finished. The momentum vanished, and the release is still
overdue. So would it has been better to break BC in this case? I tend to
say yes.

Or let's discuss another component: [lang]. The last major release
happened about 5 years ago. In software business these are ages. So
would it make sense to start working on a new version focusing on Java 8
and better support for Lambdas? We could at least start something in an
experimental branch or the sandbox to experiment with new functionality.
But it is obviously not our style to do this.

It is certainly difficult to find the right balance between stability
and innovation. For our fundamental components it is for sure no good
idea to push out an incompatible major release every few months. But
every 3 or 4 years when there are significant changes in the Java
ecosystem would probably be okay.

My $0.02
Oliver

> 
> Benedikt
> 

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

Re: Apache Code of Conduct

[Harsh Kumar]

Well thanks !  I am new in open source . This helped a lot .

On Sunday, June 5, 2016, James Carman  wrote:

> No, only if it is *enforced* will people start to feel safe and throw out
> their new ideas. The trick is making people aware that poor behavior won't
> be tolerated. Enforcement starts with the community stepping in and saying
> "now, that was uncalled for" or "we do not allow personal attacks" or
> whatever. Admittedly, we haven't done a good job of this in the past. I'm
> all for having this Code of Conduct prominently displayed, but we have to
> come together as a community and make it known that it is going to be
> observed.
>
> On Sun, Jun 5, 2016 at 5:28 AM Stian Soiland-Reyes  > wrote:
>
> > +1, showing the Code of Conduct is important also to encourage
> > contributions and engagement from underrepresented groups.
> > On 5 Jun 2016 8:47 a.m., "Benedikt Ritter"  > wrote:
> >
> > +1
> >
> > Gary Gregory > schrieb am So., 5.
> Juni 2016 um
> > 03:04:
> >
> > > On Sat, Jun 4, 2016 at 5:06 PM, Niall Pemberton <
> > niall.pember...@gmail.com 
> > > >
> > > wrote:
> > >
> > > > On Sun, Jun 5, 2016 at 12:56 AM, Gary Gregory <
> garydgreg...@gmail.com >
> > > > wrote:
> > > >
> > > > > On Sat, Jun 4, 2016 at 4:53 PM, Niall Pemberton <
> > > > niall.pember...@gmail.com 
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Apache has a "Code of Conduct" here:
> > > > > > http://www.apache.org/foundation/policies/conduct.html
> > > > > >
> > > > > > I think we should include a link to it on the Commons Site - does
> > > > anyone
> > > > > > object to that?
> > > > > >
> > > > >
> > > > > No objection, could it go under "GENERAL INFORMATION" or under the
> > > stock
> > > > > "ASF" we pick up?
> > > > >
> > > >
> > > > Yes, my preference would be under "ASF" as its an foundation
> > doc/policy,
> > > >
> > >
> > > That's my preference as well.
> > >
> > > Gary
> > >
> > >
> > > >
> > > > Niall
> > > >
> > > >
> > > > >
> > > > > Gary
> > > > >
> > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Niall
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > 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
> > >
> >
>

Re: Apache Code of Conduct

[James Carman]

No, only if it is *enforced* will people start to feel safe and throw out
their new ideas. The trick is making people aware that poor behavior won't
be tolerated. Enforcement starts with the community stepping in and saying
"now, that was uncalled for" or "we do not allow personal attacks" or
whatever. Admittedly, we haven't done a good job of this in the past. I'm
all for having this Code of Conduct prominently displayed, but we have to
come together as a community and make it known that it is going to be
observed.

On Sun, Jun 5, 2016 at 5:28 AM Stian Soiland-Reyes  wrote:

> +1, showing the Code of Conduct is important also to encourage
> contributions and engagement from underrepresented groups.
> On 5 Jun 2016 8:47 a.m., "Benedikt Ritter"  wrote:
>
> +1
>
> Gary Gregory  schrieb am So., 5. Juni 2016 um
> 03:04:
>
> > On Sat, Jun 4, 2016 at 5:06 PM, Niall Pemberton <
> niall.pember...@gmail.com
> > >
> > wrote:
> >
> > > On Sun, Jun 5, 2016 at 12:56 AM, Gary Gregory 
> > > wrote:
> > >
> > > > On Sat, Jun 4, 2016 at 4:53 PM, Niall Pemberton <
> > > niall.pember...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Apache has a "Code of Conduct" here:
> > > > > http://www.apache.org/foundation/policies/conduct.html
> > > > >
> > > > > I think we should include a link to it on the Commons Site - does
> > > anyone
> > > > > object to that?
> > > > >
> > > >
> > > > No objection, could it go under "GENERAL INFORMATION" or under the
> > stock
> > > > "ASF" we pick up?
> > > >
> > >
> > > Yes, my preference would be under "ASF" as its an foundation
> doc/policy,
> > >
> >
> > That's my preference as well.
> >
> > Gary
> >
> >
> > >
> > > Niall
> > >
> > >
> > > >
> > > > Gary
> > > >
> > > >
> > > > > Thanks
> > > > >
> > > > > Niall
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> > > >
> > >
> >
> >
> >
> > --
> > 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
> >
>

Re: Binary compatibility report

[Stian Soiland-Reyes]

I think one advantage is that this timeline output shows all the registered
versions, while Clirr is just for the "previous" version (?). Perhaps it is
also more user-friendly presentation?
On 5 Jun 2016 7:59 a.m., "Benedikt Ritter"  wrote:

> How would that be different from Clirr?
>
> Gary Gregory  schrieb am So., 5. Juni 2016 um
> 03:06:
>
> > I would be neat to turn this into a Maven plugin that generates a report
> as
> > part of the generated site.
> >
> > Gary
> >
> > On Sat, Jun 4, 2016 at 7:19 AM, Ponomarenko Andrey <
> > andrewponomare...@yandex.ru> wrote:
> >
> > > Hello,
> > >
> > > I've just prepared the report on backward compatibility for the Commons
> > IO
> > > library (BC — binary compatibility, SC — source compatibility):
> > > http://abi-laboratory.pro/java/tracker/timeline/commons-io/
> > >
> > > The report is generated daily by the japi-compliance-checker and
> > > japi-tracker tools:
> > >
> > > https://github.com/lvc/japi-compliance-checker (generates individual
> > > reports for particular versions of the library)
> > > https://github.com/lvc/japi-tracker (generates the timeline report)
> > >
> > > I can add more libraries to the tracker if somebody is interested (just
> > > reply this Email with the list of library names to add). Current list
> of
> > > maintained libraries: http://abi-laboratory.pro/java/tracker/
> > >
> > > Thank you.
> > >
> > > -
> > > 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
> >
>

Re: Apache Code of Conduct

[Stian Soiland-Reyes]

+1, showing the Code of Conduct is important also to encourage
contributions and engagement from underrepresented groups.
On 5 Jun 2016 8:47 a.m., "Benedikt Ritter"  wrote:

+1

Gary Gregory  schrieb am So., 5. Juni 2016 um 03:04:

> On Sat, Jun 4, 2016 at 5:06 PM, Niall Pemberton  >
> wrote:
>
> > On Sun, Jun 5, 2016 at 12:56 AM, Gary Gregory 
> > wrote:
> >
> > > On Sat, Jun 4, 2016 at 4:53 PM, Niall Pemberton <
> > niall.pember...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Apache has a "Code of Conduct" here:
> > > > http://www.apache.org/foundation/policies/conduct.html
> > > >
> > > > I think we should include a link to it on the Commons Site - does
> > anyone
> > > > object to that?
> > > >
> > >
> > > No objection, could it go under "GENERAL INFORMATION" or under the
> stock
> > > "ASF" we pick up?
> > >
> >
> > Yes, my preference would be under "ASF" as its an foundation doc/policy,
> >
>
> That's my preference as well.
>
> Gary
>
>
> >
> > Niall
> >
> >
> > >
> > > Gary
> > >
> > >
> > > > Thanks
> > > >
> > > > Niall
> > > >
> > >
> > >
> > >
> > > --
> > > 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
> > >
> >
>
>
>
> --
> 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
>

Re: Binary compatibility report

[sebb]

On 4 June 2016 at 15:19, Ponomarenko Andrey  wrote:
> Hello,
>
> I've just prepared the report on backward compatibility for the Commons IO 
> library (BC — binary compatibility, SC — source compatibility): 
> http://abi-laboratory.pro/java/tracker/timeline/commons-io/

Thanks for the links.

However I found it difficult to understand the output.
For example, why are some backgrounds green and some yellow?

Also, what are the rules that are used to determine whether or not a
change affects compatibility?
How do these compare with Clirr?

I think there's a bug:

The low level warning here

http://abi-laboratory.pro/java/tracker/compat_report/commons-io/1.4/2.0/8be39/bin_compat_report.html#Type_Problems_Low

says that it was caused by the change:

"Added super-class java.lang.Object."

That's not possible as a change.

> The report is generated daily by the japi-compliance-checker and japi-tracker 
> tools:
>
> https://github.com/lvc/japi-compliance-checker (generates individual reports 
> for particular versions of the library)
> https://github.com/lvc/japi-tracker (generates the timeline report)
>
> I can add more libraries to the tracker if somebody is interested (just reply 
> this Email with the list of library names to add). Current list of maintained 
> libraries: http://abi-laboratory.pro/java/tracker/
>
> Thank you.
>
> -
> 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] Javadoc

[Benedikt Ritter]

Hi,

Gary Gregory  schrieb am So., 5. Juni 2016 um
05:24 Uhr:

> I think it would be nice to have a link to a Javadoc site for ALL
> components in one lump.
>
> This would go on the main page.


> Thoughts?
>

I don't have a need for this. If you're looking for a way to browse all the
JavaDocs, I recommend a tool like Dash [1] (for Mac) or Velocity [2] (for
Windows).

Adding an aggregation page would only be okay for me if it doesn't require
an additional step in our release process.

Benedikt

[1] https://kapeli.com/dash
[2] http://velocity.silverlakesoftware.com


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

Re: [all] Javadoc

[sebb]

On 5 June 2016 at 04:24, Gary Gregory  wrote:
> I think it would be nice to have a link to a Javadoc site for ALL
> components in one lump.
>
> This would go on the main page.
>
> Thoughts?

Not sure I see the need.

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

Re: Apache Code of Conduct

[Benedikt Ritter]

+1

Gary Gregory  schrieb am So., 5. Juni 2016 um 03:04:

> On Sat, Jun 4, 2016 at 5:06 PM, Niall Pemberton  >
> wrote:
>
> > On Sun, Jun 5, 2016 at 12:56 AM, Gary Gregory 
> > wrote:
> >
> > > On Sat, Jun 4, 2016 at 4:53 PM, Niall Pemberton <
> > niall.pember...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Apache has a "Code of Conduct" here:
> > > > http://www.apache.org/foundation/policies/conduct.html
> > > >
> > > > I think we should include a link to it on the Commons Site - does
> > anyone
> > > > object to that?
> > > >
> > >
> > > No objection, could it go under "GENERAL INFORMATION" or under the
> stock
> > > "ASF" we pick up?
> > >
> >
> > Yes, my preference would be under "ASF" as its an foundation doc/policy,
> >
>
> That's my preference as well.
>
> Gary
>
>
> >
> > Niall
> >
> >
> > >
> > > Gary
> > >
> > >
> > > > Thanks
> > > >
> > > > Niall
> > > >
> > >
> > >
> > >
> > > --
> > > 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
> > >
> >
>
>
>
> --
> 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
>