Re: [ALL] About binary compatibility

[Jörg Schaible]

Hi,

James Carman wrote:

> Agree we should have a "source of truth". Is there something wrong with
> using an "internal" or "impl" package name? The bundle plugin for OSGi
> doesn't export these by default, which would be a nice side effect! :).

While it is a step in the right direction, a package scoped solution does 
not solve the problem of a public interface that should not be implemented 
directly (as we've seen with the BCEL visitor). Time for Java 8 and its 
default implementations ...

Cheers,
Jörg


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

Re: [VOTE] Move Apache Commons Primitives to dormant

[Jörg Schaible]

Benedikt Ritter wrote:

> Hi,
> 
> there hasn't been any activity in the primitives component for a long
> while:
> 
> - last release dates back to 2003-11-05
> - using svn log -l 50
> http://svn.apache.org/repos/asf/commons/proper/primitives/trunk I did not
> find a single commit that changed any of the code
> - no activity on dev@ and user@
> 
> I think we can conclude that there is no more interest in this component.
> For this reason I'm calling a vote for moving the Apache Commons
> Primitives component to dormant. This vote will close no sooner that 72
> hours from now, i.e. sometime after 17:30 CEST 12-June 2016.
> 
> [ ] +1, yes move Primitives to dormant
> [ ] +/- 0, I'm not sure...
> [ ] -1, no, do NOT move Primitives to dormant, because...
> 
> Thank you,
> Benedikt


+1


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

Re: Re: [ALL] About binary compatibility

[Andrey Loskutov]

I like the way Eclipse it does for years:

1) Everything inside **/internal/ packages is non API by definition
2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published" packages
3) Javadoc @noextend tag for classes not intended to be extended
4) Javadoc @noimplement tag for interfaces

A bonus for libraries with correct MANIFEST.MF is that they can be directly 
used as bundles inside any OSGI container (also Eclipse).

Example:
/**
 * An observable value whose changes can be vetoed by listeners.
 *
 * @param 
 *the type of value being observed
 *
 * @noextend This interface is not intended to be extended by clients.
 * @noimplement This interface is not intended to be implemented by clients.
 *  Clients should instead subclass one of the classes that
 *  implement this interface. Note that direct implementers of this
 *  interface outside of the framework will be broken in future
 *  releases when methods are added to this interface.
 *
 * @since 1.0
 *
 */
public interface IVetoableValue extends IObservableValue {

Kind regards,
Andrey Loskutov

http://google.com/+AndreyLoskutov


> Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> Von: "Jörg Schaible" 
> An: dev@commons.apache.org
> Betreff: Re: [ALL] About binary compatibility
>
> Hi,
> 
> James Carman wrote:
> 
> > Agree we should have a "source of truth". Is there something wrong with
> > using an "internal" or "impl" package name? The bundle plugin for OSGi
> > doesn't export these by default, which would be a nice side effect! :).
> 
> While it is a step in the right direction, a package scoped solution does 
> not solve the problem of a public interface that should not be implemented 
> directly (as we've seen with the BCEL visitor). Time for Java 8 and its 
> default implementations ...
> 
> Cheers,
> Jörg

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

RE: [crypto] On Java 6, really?

[Sun, Dapeng]

Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and Matt for 
all your input.

How about make a conservative decision: regarding the first release(1.0.0), we 
keep the JDK version as 1.6, and we wouldn't support JDK 1.6 for the releases 
after 1.0.0. 

Regards
Dapeng

-Original Message-
From: Matt Sicker [mailto:boa...@gmail.com] 
Sent: Wednesday, June 08, 2016 6:18 AM
To: Commons Developers List
Subject: Re: [crypto] On Java 6, really?

I'd imagine that close to 100% of users who are on Java 6 are not upgrading 
anything else, either, nor would they be adding in new dependencies. Every Java 
6 project I've come across lately has been in legacy maintenance mode (just 
like Java 6 itself).

On 7 June 2016 at 16:47, Gary Gregory  wrote:

> Let's not forget that customers are paying Oracle to get Java 6 updates.
>
> Gary
> On Jun 7, 2016 1:24 PM, "Ralph Goers"  wrote:
>
> > I really don’t think the premier & extended support dates should 
> > really mean much, except as an indicator of how many users of that 
> > version might still exist.  Basically, no new features are going to 
> > be added to Java
> so I
> > don’t think we should be targeting new features there either. If 
> > there
> is a
> > bug that needs to be fixed it should be possible to do it on a 
> > branch of the the release for that version of Java.  The web site 
> > should clearly indicate which versions of the component support the 
> > appropriate Java versions.
> >
> > Ralph
> >
> > > On Jun 7, 2016, at 12:26 PM, sebb  wrote:
> > >
> > > I have just checked Oracle support for Java 6.
> > >
> > > The Support Life for Java 6 has been extended to Dec 2018 [1] I 
> > > think this means that there are critical systems that cannot yet 
> > > be updated to Java 7+.
> > >
> > > This does not mean that we should ensure that all Commons code 
> > > still works on Java 6.
> > > But it should be taken into account when evaluating the pros and 
> > > cons of requiring a later version.
> > >
> > > [1] 
> > > http://www.oracle.com/technetwork/java/eol-135779.html#extended6
> > >
> > > On 7 June 2016 at 20:02, Jochen Wiedmann 
> > > 
> > wrote:
> > >>> Gary Gregory  wrote on Tue., 7. Juni 
> > >>> 2016
> > >>>
> >  Are we really starting a new component on a dead platform like 
> >  Java
> 6?
> > >>
> > >>
> > >> You are, of course, right, that the component is more than 
> > >> welcome to use another version. OTOH, given our latest 
> > >> experiences: Is this really someting, that we should care for? 
> > >> IMO, let the component have, whatever they want.
> > >>
> > >> Jochen
> > >>
> > >> -
> > >>  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
> >
> >
>



--
Matt Sicker 

Re: [crypto] On Java 6, really?

[Gangumalla, Uma]

Then next release(after 1.0.0) must be a major release you mean?
If there are no potential users looking for JDK 1.6, dropping now should
be good idea IMO.

I also remembered that we wanted to mark 1.0.0 release as Alpha right?
(just a question)

Regards,
Uma

On 6/14/16, 12:27 AM, "Sun, Dapeng"  wrote:

>Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and Matt
>for all your input.
>
>How about make a conservative decision: regarding the first
>release(1.0.0), we keep the JDK version as 1.6, and we wouldn't support
>JDK 1.6 for the releases after 1.0.0.
>
>Regards
>Dapeng
>
>-Original Message-
>From: Matt Sicker [mailto:boa...@gmail.com]
>Sent: Wednesday, June 08, 2016 6:18 AM
>To: Commons Developers List
>Subject: Re: [crypto] On Java 6, really?
>
>I'd imagine that close to 100% of users who are on Java 6 are not
>upgrading anything else, either, nor would they be adding in new
>dependencies. Every Java 6 project I've come across lately has been in
>legacy maintenance mode (just like Java 6 itself).
>
>On 7 June 2016 at 16:47, Gary Gregory  wrote:
>
>> Let's not forget that customers are paying Oracle to get Java 6 updates.
>>
>> Gary
>> On Jun 7, 2016 1:24 PM, "Ralph Goers" 
>>wrote:
>>
>> > I really don¹t think the premier & extended support dates should
>> > really mean much, except as an indicator of how many users of that
>> > version might still exist.  Basically, no new features are going to
>> > be added to Java
>> so I
>> > don¹t think we should be targeting new features there either. If
>> > there
>> is a
>> > bug that needs to be fixed it should be possible to do it on a
>> > branch of the the release for that version of Java.  The web site
>> > should clearly indicate which versions of the component support the
>> > appropriate Java versions.
>> >
>> > Ralph
>> >
>> > > On Jun 7, 2016, at 12:26 PM, sebb  wrote:
>> > >
>> > > I have just checked Oracle support for Java 6.
>> > >
>> > > The Support Life for Java 6 has been extended to Dec 2018 [1] I
>> > > think this means that there are critical systems that cannot yet
>> > > be updated to Java 7+.
>> > >
>> > > This does not mean that we should ensure that all Commons code
>> > > still works on Java 6.
>> > > But it should be taken into account when evaluating the pros and
>> > > cons of requiring a later version.
>> > >
>> > > [1] 
>> > > http://www.oracle.com/technetwork/java/eol-135779.html#extended6
>> > >
>> > > On 7 June 2016 at 20:02, Jochen Wiedmann
>> > > 
>> > wrote:
>> > >>> Gary Gregory  wrote on Tue., 7. Juni
>> > >>> 2016
>> > >>>
>> >  Are we really starting a new component on a dead platform like
>> >  Java
>> 6?
>> > >>
>> > >>
>> > >> You are, of course, right, that the component is more than
>> > >> welcome to use another version. OTOH, given our latest
>> > >> experiences: Is this really someting, that we should care for?
>> > >> IMO, let the component have, whatever they want.
>> > >>
>> > >> Jochen
>> > >>
>> > >> -
>> > >>  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
>> >
>> >
>>
>
>
>
>--
>Matt Sicker 


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

Re: [crypto] On Java 6, really?

[Gary Gregory]

On Tue, Jun 14, 2016 at 1:21 AM, Gangumalla, Uma 
wrote:

> Then next release(after 1.0.0) must be a major release you mean?
> If there are no potential users looking for JDK 1.6, dropping now should
> be good idea IMO.
>
> I also remembered that we wanted to mark 1.0.0 release as Alpha right?
> (just a question)
>

1.0 is 1.0. If we want an alpha, we must label is as such, for example
1.0-alpha1, 1.0-beta1. There is no 1.0 is an alpha and 1.1 is a "real"
release.

Gary

>
> Regards,
> Uma
>
> On 6/14/16, 12:27 AM, "Sun, Dapeng"  wrote:
>
> >Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and Matt
> >for all your input.
> >
> >How about make a conservative decision: regarding the first
> >release(1.0.0), we keep the JDK version as 1.6, and we wouldn't support
> >JDK 1.6 for the releases after 1.0.0.
> >
> >Regards
> >Dapeng
> >
> >-Original Message-
> >From: Matt Sicker [mailto:boa...@gmail.com]
> >Sent: Wednesday, June 08, 2016 6:18 AM
> >To: Commons Developers List
> >Subject: Re: [crypto] On Java 6, really?
> >
> >I'd imagine that close to 100% of users who are on Java 6 are not
> >upgrading anything else, either, nor would they be adding in new
> >dependencies. Every Java 6 project I've come across lately has been in
> >legacy maintenance mode (just like Java 6 itself).
> >
> >On 7 June 2016 at 16:47, Gary Gregory  wrote:
> >
> >> Let's not forget that customers are paying Oracle to get Java 6 updates.
> >>
> >> Gary
> >> On Jun 7, 2016 1:24 PM, "Ralph Goers" 
> >>wrote:
> >>
> >> > I really don¹t think the premier & extended support dates should
> >> > really mean much, except as an indicator of how many users of that
> >> > version might still exist.  Basically, no new features are going to
> >> > be added to Java
> >> so I
> >> > don¹t think we should be targeting new features there either. If
> >> > there
> >> is a
> >> > bug that needs to be fixed it should be possible to do it on a
> >> > branch of the the release for that version of Java.  The web site
> >> > should clearly indicate which versions of the component support the
> >> > appropriate Java versions.
> >> >
> >> > Ralph
> >> >
> >> > > On Jun 7, 2016, at 12:26 PM, sebb  wrote:
> >> > >
> >> > > I have just checked Oracle support for Java 6.
> >> > >
> >> > > The Support Life for Java 6 has been extended to Dec 2018 [1] I
> >> > > think this means that there are critical systems that cannot yet
> >> > > be updated to Java 7+.
> >> > >
> >> > > This does not mean that we should ensure that all Commons code
> >> > > still works on Java 6.
> >> > > But it should be taken into account when evaluating the pros and
> >> > > cons of requiring a later version.
> >> > >
> >> > > [1]
> >> > > http://www.oracle.com/technetwork/java/eol-135779.html#extended6
> >> > >
> >> > > On 7 June 2016 at 20:02, Jochen Wiedmann
> >> > > 
> >> > wrote:
> >> > >>> Gary Gregory  wrote on Tue., 7. Juni
> >> > >>> 2016
> >> > >>>
> >> >  Are we really starting a new component on a dead platform like
> >> >  Java
> >> 6?
> >> > >>
> >> > >>
> >> > >> You are, of course, right, that the component is more than
> >> > >> welcome to use another version. OTOH, given our latest
> >> > >> experiences: Is this really someting, that we should care for?
> >> > >> IMO, let the component have, whatever they want.
> >> > >>
> >> > >> Jochen
> >> > >>
> >> > >> -
> >> > >>  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
> >> >
> >> >
> >>
> >
> >
> >
> >--
> >Matt Sicker 
>
>
> -
> 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: [crypto] On Java 6, really?

[Gangumalla, Uma]

On 6/14/16, 1:23 AM, "Gary Gregory"  wrote:

>On Tue, Jun 14, 2016 at 1:21 AM, Gangumalla, Uma
>
>wrote:
>
>> Then next release(after 1.0.0) must be a major release you mean?
>> If there are no potential users looking for JDK 1.6, dropping now should
>> be good idea IMO.
>>
>> I also remembered that we wanted to mark 1.0.0 release as Alpha right?
>> (just a question)
>>
>
>1.0 is 1.0. If we want an alpha, we must label is as such, for example
>1.0-alpha1, 1.0-beta1. There is no 1.0 is an alpha and 1.1 is a "real"
>release.

Yeah, right on naming.
What others think on that?
>
>Gary
>
>>
>> Regards,
>> Uma
>>
>> On 6/14/16, 12:27 AM, "Sun, Dapeng"  wrote:
>>
>> >Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and
>>Matt
>> >for all your input.
>> >
>> >How about make a conservative decision: regarding the first
>> >release(1.0.0), we keep the JDK version as 1.6, and we wouldn't support
>> >JDK 1.6 for the releases after 1.0.0.
>> >
>> >Regards
>> >Dapeng
>> >
>> >-Original Message-
>> >From: Matt Sicker [mailto:boa...@gmail.com]
>> >Sent: Wednesday, June 08, 2016 6:18 AM
>> >To: Commons Developers List
>> >Subject: Re: [crypto] On Java 6, really?
>> >
>> >I'd imagine that close to 100% of users who are on Java 6 are not
>> >upgrading anything else, either, nor would they be adding in new
>> >dependencies. Every Java 6 project I've come across lately has been in
>> >legacy maintenance mode (just like Java 6 itself).
>> >
>> >On 7 June 2016 at 16:47, Gary Gregory  wrote:
>> >
>> >> Let's not forget that customers are paying Oracle to get Java 6
>>updates.
>> >>
>> >> Gary
>> >> On Jun 7, 2016 1:24 PM, "Ralph Goers" 
>> >>wrote:
>> >>
>> >> > I really don¹t think the premier & extended support dates should
>> >> > really mean much, except as an indicator of how many users of that
>> >> > version might still exist.  Basically, no new features are going to
>> >> > be added to Java
>> >> so I
>> >> > don¹t think we should be targeting new features there either. If
>> >> > there
>> >> is a
>> >> > bug that needs to be fixed it should be possible to do it on a
>> >> > branch of the the release for that version of Java.  The web site
>> >> > should clearly indicate which versions of the component support the
>> >> > appropriate Java versions.
>> >> >
>> >> > Ralph
>> >> >
>> >> > > On Jun 7, 2016, at 12:26 PM, sebb  wrote:
>> >> > >
>> >> > > I have just checked Oracle support for Java 6.
>> >> > >
>> >> > > The Support Life for Java 6 has been extended to Dec 2018 [1] I
>> >> > > think this means that there are critical systems that cannot yet
>> >> > > be updated to Java 7+.
>> >> > >
>> >> > > This does not mean that we should ensure that all Commons code
>> >> > > still works on Java 6.
>> >> > > But it should be taken into account when evaluating the pros and
>> >> > > cons of requiring a later version.
>> >> > >
>> >> > > [1]
>> >> > > http://www.oracle.com/technetwork/java/eol-135779.html#extended6
>> >> > >
>> >> > > On 7 June 2016 at 20:02, Jochen Wiedmann
>> >> > > 
>> >> > wrote:
>> >> > >>> Gary Gregory  wrote on Tue., 7. Juni
>> >> > >>> 2016
>> >> > >>>
>> >> >  Are we really starting a new component on a dead platform like
>> >> >  Java
>> >> 6?
>> >> > >>
>> >> > >>
>> >> > >> You are, of course, right, that the component is more than
>> >> > >> welcome to use another version. OTOH, given our latest
>> >> > >> experiences: Is this really someting, that we should care for?
>> >> > >> IMO, let the component have, whatever they want.
>> >> > >>
>> >> > >> Jochen
>> >> > >>
>> >> > >> 
>>-
>> >> > >>  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
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>> >--
>> >Matt Sicker 
>>
>>
>> -
>> 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: [VOTE] Move Apache Commons Primitives to dormant

[Jochen Wiedmann]

+1 (IMO, primitives is redundant anyways, because of commons-lang)

Jochen


On Tue, Jun 14, 2016 at 9:06 AM, Jörg Schaible
 wrote:
> Benedikt Ritter wrote:
>
>> Hi,
>>
>> there hasn't been any activity in the primitives component for a long
>> while:
>>
>> - last release dates back to 2003-11-05
>> - using svn log -l 50
>> http://svn.apache.org/repos/asf/commons/proper/primitives/trunk I did not
>> find a single commit that changed any of the code
>> - no activity on dev@ and user@
>>
>> I think we can conclude that there is no more interest in this component.
>> For this reason I'm calling a vote for moving the Apache Commons
>> Primitives component to dormant. This vote will close no sooner that 72
>> hours from now, i.e. sometime after 17:30 CEST 12-June 2016.
>>
>> [ ] +1, yes move Primitives to dormant
>> [ ] +/- 0, I'm not sure...
>> [ ] -1, no, do NOT move Primitives to dormant, because...
>>
>> Thank you,
>> Benedikt
>
>
> +1
>
>
> -
> 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

RE: [crypto] On Java 6, really?

[Sun, Dapeng]

> Then next release(after 1.0.0) must be a major release you mean?
> If there are no potential users looking for JDK 1.6, dropping now should be 
> good idea IMO.

Thank Uma, I just checked there is no much changes on upgrading JDK to 1.7, I 
think we can upgrade before this release. 

Is there anyone have other opinions?

Regards
Dapeng

-Original Message-
From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com] 
Sent: Tuesday, June 14, 2016 4:21 PM
To: Commons Developers List
Subject: Re: [crypto] On Java 6, really?

Then next release(after 1.0.0) must be a major release you mean?
If there are no potential users looking for JDK 1.6, dropping now should be 
good idea IMO.

I also remembered that we wanted to mark 1.0.0 release as Alpha right?
(just a question)

Regards,
Uma

On 6/14/16, 12:27 AM, "Sun, Dapeng"  wrote:

>Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and 
>Matt for all your input.
>
>How about make a conservative decision: regarding the first 
>release(1.0.0), we keep the JDK version as 1.6, and we wouldn't support 
>JDK 1.6 for the releases after 1.0.0.
>
>Regards
>Dapeng
>
>-Original Message-
>From: Matt Sicker [mailto:boa...@gmail.com]
>Sent: Wednesday, June 08, 2016 6:18 AM
>To: Commons Developers List
>Subject: Re: [crypto] On Java 6, really?
>
>I'd imagine that close to 100% of users who are on Java 6 are not 
>upgrading anything else, either, nor would they be adding in new 
>dependencies. Every Java 6 project I've come across lately has been in 
>legacy maintenance mode (just like Java 6 itself).
>
>On 7 June 2016 at 16:47, Gary Gregory  wrote:
>
>> Let's not forget that customers are paying Oracle to get Java 6 updates.
>>
>> Gary
>> On Jun 7, 2016 1:24 PM, "Ralph Goers" 
>>wrote:
>>
>> > I really don¹t think the premier & extended support dates should 
>> > really mean much, except as an indicator of how many users of that 
>> > version might still exist.  Basically, no new features are going to 
>> > be added to Java
>> so I
>> > don¹t think we should be targeting new features there either. If 
>> > there
>> is a
>> > bug that needs to be fixed it should be possible to do it on a 
>> > branch of the the release for that version of Java.  The web site 
>> > should clearly indicate which versions of the component support the 
>> > appropriate Java versions.
>> >
>> > Ralph
>> >
>> > > On Jun 7, 2016, at 12:26 PM, sebb  wrote:
>> > >
>> > > I have just checked Oracle support for Java 6.
>> > >
>> > > The Support Life for Java 6 has been extended to Dec 2018 [1] I 
>> > > think this means that there are critical systems that cannot yet 
>> > > be updated to Java 7+.
>> > >
>> > > This does not mean that we should ensure that all Commons code 
>> > > still works on Java 6.
>> > > But it should be taken into account when evaluating the pros and 
>> > > cons of requiring a later version.
>> > >
>> > > [1]
>> > > http://www.oracle.com/technetwork/java/eol-135779.html#extended6
>> > >
>> > > On 7 June 2016 at 20:02, Jochen Wiedmann 
>> > > 
>> > wrote:
>> > >>> Gary Gregory  wrote on Tue., 7. Juni
>> > >>> 2016
>> > >>>
>> >  Are we really starting a new component on a dead platform like 
>> >  Java
>> 6?
>> > >>
>> > >>
>> > >> You are, of course, right, that the component is more than 
>> > >> welcome to use another version. OTOH, given our latest
>> > >> experiences: Is this really someting, that we should care for?
>> > >> IMO, let the component have, whatever they want.
>> > >>
>> > >> Jochen
>> > >>
>> > >> 
>> > >> -
>> > >>  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
>> >
>> >
>>
>
>
>
>--
>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: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

[sebb]

On 14 June 2016 at 07:13, Benedikt Ritter  wrote:
> I don't like how we're evolving CSVFormat. It is becoming a dumping ground
> for anything that may be useful or convenient. The more methods we add, the
> harder it becomes for users to find the right method for their use case.

+1

And the more maintenance, documentation and testing that is needed.

> Benedikt
>
>  schrieb am Di., 14. Juni 2016 um 07:53 Uhr:
>
>> Author: ggregory
>> Date: Tue Jun 14 05:53:32 2016
>> New Revision: 1748347
>>
>> URL: http://svn.apache.org/viewvc?rev=1748347&view=rev
>> Log:
>> Add convenience API CSVFormat.print(File, Charset) (JIRA is down ATM).
>>
>> Modified:
>> commons/proper/csv/trunk/src/changes/changes.xml
>>
>> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>>
>> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
>>
>> Modified: commons/proper/csv/trunk/src/changes/changes.xml
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/changes/changes.xml?rev=1748347&r1=1748346&r2=1748347&view=diff
>>
>> ==
>> --- commons/proper/csv/trunk/src/changes/changes.xml (original)
>> +++ commons/proper/csv/trunk/src/changes/changes.xml Tue Jun 14 05:53:32
>> 2016
>> @@ -40,6 +40,7 @@
>>
>>  
>>Update platform requirement from Java 6 to 7.
>> +  Add convenience API CSVFormat.print(File, Charset)
>>  
>>  
>>Make CSVPrinter.print(Object) GC-free.
>>
>> Modified:
>> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1748347&r1=1748346&r2=1748347&view=diff
>>
>> ==
>> ---
>> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>> (original)
>> +++
>> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>> Tue Jun 14 05:53:32 2016
>> @@ -28,10 +28,14 @@ import static org.apache.commons.csv.Con
>>  import static org.apache.commons.csv.Constants.SP;
>>  import static org.apache.commons.csv.Constants.TAB;
>>
>> +import java.io.File;
>> +import java.io.FileOutputStream;
>>  import java.io.IOException;
>> +import java.io.OutputStreamWriter;
>>  import java.io.Reader;
>>  import java.io.Serializable;
>>  import java.io.StringWriter;
>> +import java.nio.charset.Charset;
>>  import java.sql.ResultSet;
>>  import java.sql.ResultSetMetaData;
>>  import java.sql.SQLException;
>> @@ -864,6 +868,27 @@ public final class CSVFormat implements
>>  }
>>
>>  /**
>> + * Prints to the specified output.
>> + *
>> + * 
>> + * See also {@link CSVPrinter}.
>> + * 
>> + *
>> + * @param out
>> + *the output
>> + * @param charset
>> + *A charset
>> + * @return a printer to an output
>> + * @throws IOException
>> + * thrown if the optional header cannot be printed.
>> + * @since 1.5
>> + */
>> +public CSVPrinter print(final File out, Charset charset) throws
>> IOException {
>> +// The FileWriter will be closed when close() is called.
>> +return new CSVPrinter(new OutputStreamWriter(new
>> FileOutputStream(out), charset), this);
>> +}
>> +
>> +/**
>>   * Prints the {@code value} as the next value on the line to {@code
>> out}. The value will be escaped or encapsulated
>>   * as needed. Useful when one wants to avoid creating CSVPrinters.
>>   *
>>
>> Modified:
>> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java?rev=1748347&r1=1748346&r2=1748347&view=diff
>>
>> ==
>> ---
>> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
>> (original)
>> +++
>> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
>> Tue Jun 14 05:53:32 2016
>> @@ -22,9 +22,12 @@ import static org.junit.Assert.assertArr
>>  import static org.junit.Assert.assertEquals;
>>  import static org.junit.Assert.assertFalse;
>>
>> +import java.io.File;
>>  import java.io.IOException;
>>  import java.io.StringReader;
>>  import java.io.StringWriter;
>> +import java.nio.charset.Charset;
>> +import java.nio.charset.StandardCharsets;
>>  import java.sql.Connection;
>>  import java.sql.DriverManager;
>>  import java.sql.ResultSet;
>> @@ -38,6 +41,7 @@ import java.util.List;
>>  import java.util.Objects;
>>  import java.util.Random;
>>
>> +import org.apache.commons.io.FileUtils;
>>  import org.junit.Assert;
>>  import org.junit.Ignore;
>>  import org.junit.Test;
>> @@ -728,6 +732,24 @@ public class CSVPrinterTest {
>>  }
>>
>

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

[sebb]

On 14 June 2016 at 07:17, Gary Gregory  wrote:
> On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter 
> wrote:
>
>> I don't like how we're evolving CSVFormat. It is becoming a dumping ground
>> for anything that may be useful or convenient. The more methods we add, the
>> harder it becomes for users to find the right method for their use case.
>>
>
> Small is nice, I get that. But how would you do it differently so that I
> can easily use Paths, Files, URI, and URLs...

Conversion between these and Appendable is not the job of CSV.

> Gary
>
>
>>
>> Benedikt
>>
>>  schrieb am Di., 14. Juni 2016 um 07:53 Uhr:
>>
>> > Author: ggregory
>> > Date: Tue Jun 14 05:53:32 2016
>> > New Revision: 1748347
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1748347&view=rev
>> > Log:
>> > Add convenience API CSVFormat.print(File, Charset) (JIRA is down ATM).
>> >
>> > Modified:
>> > commons/proper/csv/trunk/src/changes/changes.xml
>> >
>> >
>> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>> >
>> >
>> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
>> >
>> > Modified: commons/proper/csv/trunk/src/changes/changes.xml
>> > URL:
>> >
>> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/changes/changes.xml?rev=1748347&r1=1748346&r2=1748347&view=diff
>> >
>> >
>> ==
>> > --- commons/proper/csv/trunk/src/changes/changes.xml (original)
>> > +++ commons/proper/csv/trunk/src/changes/changes.xml Tue Jun 14 05:53:32
>> > 2016
>> > @@ -40,6 +40,7 @@
>> >
>> >  
>> >Update platform requirement from Java 6 to 7.
>> > +  Add convenience API CSVFormat.print(File, Charset)
>> >  
>> >  
>> >Make CSVPrinter.print(Object) GC-free.
>> >
>> > Modified:
>> >
>> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>> > URL:
>> >
>> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1748347&r1=1748346&r2=1748347&view=diff
>> >
>> >
>> ==
>> > ---
>> >
>> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>> > (original)
>> > +++
>> >
>> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>> > Tue Jun 14 05:53:32 2016
>> > @@ -28,10 +28,14 @@ import static org.apache.commons.csv.Con
>> >  import static org.apache.commons.csv.Constants.SP;
>> >  import static org.apache.commons.csv.Constants.TAB;
>> >
>> > +import java.io.File;
>> > +import java.io.FileOutputStream;
>> >  import java.io.IOException;
>> > +import java.io.OutputStreamWriter;
>> >  import java.io.Reader;
>> >  import java.io.Serializable;
>> >  import java.io.StringWriter;
>> > +import java.nio.charset.Charset;
>> >  import java.sql.ResultSet;
>> >  import java.sql.ResultSetMetaData;
>> >  import java.sql.SQLException;
>> > @@ -864,6 +868,27 @@ public final class CSVFormat implements
>> >  }
>> >
>> >  /**
>> > + * Prints to the specified output.
>> > + *
>> > + * 
>> > + * See also {@link CSVPrinter}.
>> > + * 
>> > + *
>> > + * @param out
>> > + *the output
>> > + * @param charset
>> > + *A charset
>> > + * @return a printer to an output
>> > + * @throws IOException
>> > + * thrown if the optional header cannot be printed.
>> > + * @since 1.5
>> > + */
>> > +public CSVPrinter print(final File out, Charset charset) throws
>> > IOException {
>> > +// The FileWriter will be closed when close() is called.
>> > +return new CSVPrinter(new OutputStreamWriter(new
>> > FileOutputStream(out), charset), this);
>> > +}
>> > +
>> > +/**
>> >   * Prints the {@code value} as the next value on the line to {@code
>> > out}. The value will be escaped or encapsulated
>> >   * as needed. Useful when one wants to avoid creating CSVPrinters.
>> >   *
>> >
>> > Modified:
>> >
>> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
>> > URL:
>> >
>> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java?rev=1748347&r1=1748346&r2=1748347&view=diff
>> >
>> >
>> ==
>> > ---
>> >
>> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
>> > (original)
>> > +++
>> >
>> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
>> > Tue Jun 14 05:53:32 2016
>> > @@ -22,9 +22,12 @@ import static org.junit.Assert.assertArr
>> >  import static org.junit.Assert.assertEquals;
>> >  import static org.junit.Assert.assertFalse;
>> >
>> > +import java.io.File;
>> >  import java.io.IOException;
>> >  import java.io.StringReader;
>> >  import java.io.StringWriter;
>> > +import java.n

Re: [DISCUSS] Brining clirr to the ASF?

[Uwe Barthel]

As Clirr is internally based on BCEL, I'd rather see us build a new
tool on top of ASM, which is very well maintained. Besides, that would
solve the license problem.


Sounds like a existing idea. I'm interested in to contribute.

-- barthel



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

RE: [crypto] On Java 6, really?

[Stian Soiland-Reyes]

+1 to JDK7 on crypto
On 14 Jun 2016 10:25 a.m., "Sun, Dapeng"  wrote:

> > Then next release(after 1.0.0) must be a major release you mean?
> > If there are no potential users looking for JDK 1.6, dropping now should
> be good idea IMO.
>
> Thank Uma, I just checked there is no much changes on upgrading JDK to
> 1.7, I think we can upgrade before this release.
>
> Is there anyone have other opinions?
>
> Regards
> Dapeng
>
> -Original Message-
> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> Sent: Tuesday, June 14, 2016 4:21 PM
> To: Commons Developers List
> Subject: Re: [crypto] On Java 6, really?
>
> Then next release(after 1.0.0) must be a major release you mean?
> If there are no potential users looking for JDK 1.6, dropping now should
> be good idea IMO.
>
> I also remembered that we wanted to mark 1.0.0 release as Alpha right?
> (just a question)
>
> Regards,
> Uma
>
> On 6/14/16, 12:27 AM, "Sun, Dapeng"  wrote:
>
> >Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and
> >Matt for all your input.
> >
> >How about make a conservative decision: regarding the first
> >release(1.0.0), we keep the JDK version as 1.6, and we wouldn't support
> >JDK 1.6 for the releases after 1.0.0.
> >
> >Regards
> >Dapeng
> >
> >-Original Message-
> >From: Matt Sicker [mailto:boa...@gmail.com]
> >Sent: Wednesday, June 08, 2016 6:18 AM
> >To: Commons Developers List
> >Subject: Re: [crypto] On Java 6, really?
> >
> >I'd imagine that close to 100% of users who are on Java 6 are not
> >upgrading anything else, either, nor would they be adding in new
> >dependencies. Every Java 6 project I've come across lately has been in
> >legacy maintenance mode (just like Java 6 itself).
> >
> >On 7 June 2016 at 16:47, Gary Gregory  wrote:
> >
> >> Let's not forget that customers are paying Oracle to get Java 6 updates.
> >>
> >> Gary
> >> On Jun 7, 2016 1:24 PM, "Ralph Goers" 
> >>wrote:
> >>
> >> > I really don¹t think the premier & extended support dates should
> >> > really mean much, except as an indicator of how many users of that
> >> > version might still exist.  Basically, no new features are going to
> >> > be added to Java
> >> so I
> >> > don¹t think we should be targeting new features there either. If
> >> > there
> >> is a
> >> > bug that needs to be fixed it should be possible to do it on a
> >> > branch of the the release for that version of Java.  The web site
> >> > should clearly indicate which versions of the component support the
> >> > appropriate Java versions.
> >> >
> >> > Ralph
> >> >
> >> > > On Jun 7, 2016, at 12:26 PM, sebb  wrote:
> >> > >
> >> > > I have just checked Oracle support for Java 6.
> >> > >
> >> > > The Support Life for Java 6 has been extended to Dec 2018 [1] I
> >> > > think this means that there are critical systems that cannot yet
> >> > > be updated to Java 7+.
> >> > >
> >> > > This does not mean that we should ensure that all Commons code
> >> > > still works on Java 6.
> >> > > But it should be taken into account when evaluating the pros and
> >> > > cons of requiring a later version.
> >> > >
> >> > > [1]
> >> > > http://www.oracle.com/technetwork/java/eol-135779.html#extended6
> >> > >
> >> > > On 7 June 2016 at 20:02, Jochen Wiedmann
> >> > > 
> >> > wrote:
> >> > >>> Gary Gregory  wrote on Tue., 7. Juni
> >> > >>> 2016
> >> > >>>
> >> >  Are we really starting a new component on a dead platform like
> >> >  Java
> >> 6?
> >> > >>
> >> > >>
> >> > >> You are, of course, right, that the component is more than
> >> > >> welcome to use another version. OTOH, given our latest
> >> > >> experiences: Is this really someting, that we should care for?
> >> > >> IMO, let the component have, whatever they want.
> >> > >>
> >> > >> Jochen
> >> > >>
> >> > >> 
> >> > >> -
> >> > >>  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
> >> >
> >> >
> >>
> >
> >
> >
> >--
> >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: [DISCUSS] Brining clirr to the ASF?

[James Carman]

+1 to Jochen's idea and I'd love to contribute to that effort!

On Tue, Jun 14, 2016 at 2:40 AM Jochen Wiedmann 
wrote:

> On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory 
> wrote:
>
> >> as Jochen has pointed out, Clirr seems to be unmaintained. However we
> build
> >> a good part of our release strategy upon clirr. So I wonder whether we
> >> should foster bringing clirr to the ASF (for example by going through
> >> incubation). We're probably not the only ASF project using Clirr.
> >>
> >
> > +1. Can we bring in code that's under GNU Lesser General Public and make
> it
> > ASL 2?
> >
> > Could fit under a new Commons Build or Clirr component since it is a
> > "common" build requirement.
>
> As Clirr is internally based on BCEL, I'd rather see us build a new
> tool on top of ASM, which is very well maintained. Besides, that would
> solve the license problem.
>
> 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
>
>

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

[James Carman]

Are Readers that hard to create?

On Tue, Jun 14, 2016 at 2:17 AM Gary Gregory  wrote:

> On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter 
> wrote:
>
> > I don't like how we're evolving CSVFormat. It is becoming a dumping
> ground
> > for anything that may be useful or convenient. The more methods we add,
> the
> > harder it becomes for users to find the right method for their use case.
> >
>
> Small is nice, I get that. But how would you do it differently so that I
> can easily use Paths, Files, URI, and URLs...
>
> Gary
>
>
> >
> > Benedikt
> >
> >  schrieb am Di., 14. Juni 2016 um 07:53 Uhr:
> >
> > > Author: ggregory
> > > Date: Tue Jun 14 05:53:32 2016
> > > New Revision: 1748347
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1748347&view=rev
> > > Log:
> > > Add convenience API CSVFormat.print(File, Charset) (JIRA is down ATM).
> > >
> > > Modified:
> > > commons/proper/csv/trunk/src/changes/changes.xml
> > >
> > >
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > >
> > >
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > >
> > > Modified: commons/proper/csv/trunk/src/changes/changes.xml
> > > URL:
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/changes/changes.xml?rev=1748347&r1=1748346&r2=1748347&view=diff
> > >
> > >
> >
> ==
> > > --- commons/proper/csv/trunk/src/changes/changes.xml (original)
> > > +++ commons/proper/csv/trunk/src/changes/changes.xml Tue Jun 14
> 05:53:32
> > > 2016
> > > @@ -40,6 +40,7 @@
> > >
> > >  
> > > due-to="Gary
> > > Gregory">Update platform requirement from Java 6 to 7.
> > > +  Add convenience API CSVFormat.print(File, Charset)
> > >  
> > >  
> > > due-to="Gary
> > > Gregory">Make CSVPrinter.print(Object) GC-free.
> > >
> > > Modified:
> > >
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > URL:
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1748347&r1=1748346&r2=1748347&view=diff
> > >
> > >
> >
> ==
> > > ---
> > >
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > (original)
> > > +++
> > >
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > Tue Jun 14 05:53:32 2016
> > > @@ -28,10 +28,14 @@ import static org.apache.commons.csv.Con
> > >  import static org.apache.commons.csv.Constants.SP;
> > >  import static org.apache.commons.csv.Constants.TAB;
> > >
> > > +import java.io.File;
> > > +import java.io.FileOutputStream;
> > >  import java.io.IOException;
> > > +import java.io.OutputStreamWriter;
> > >  import java.io.Reader;
> > >  import java.io.Serializable;
> > >  import java.io.StringWriter;
> > > +import java.nio.charset.Charset;
> > >  import java.sql.ResultSet;
> > >  import java.sql.ResultSetMetaData;
> > >  import java.sql.SQLException;
> > > @@ -864,6 +868,27 @@ public final class CSVFormat implements
> > >  }
> > >
> > >  /**
> > > + * Prints to the specified output.
> > > + *
> > > + * 
> > > + * See also {@link CSVPrinter}.
> > > + * 
> > > + *
> > > + * @param out
> > > + *the output
> > > + * @param charset
> > > + *A charset
> > > + * @return a printer to an output
> > > + * @throws IOException
> > > + * thrown if the optional header cannot be printed.
> > > + * @since 1.5
> > > + */
> > > +public CSVPrinter print(final File out, Charset charset) throws
> > > IOException {
> > > +// The FileWriter will be closed when close() is called.
> > > +return new CSVPrinter(new OutputStreamWriter(new
> > > FileOutputStream(out), charset), this);
> > > +}
> > > +
> > > +/**
> > >   * Prints the {@code value} as the next value on the line to
> {@code
> > > out}. The value will be escaped or encapsulated
> > >   * as needed. Useful when one wants to avoid creating CSVPrinters.
> > >   *
> > >
> > > Modified:
> > >
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > > URL:
> > >
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java?rev=1748347&r1=1748346&r2=1748347&view=diff
> > >
> > >
> >
> ==
> > > ---
> > >
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > > (original)
> > > +++
> > >
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > > Tue Jun 14 05:53:32 2016
> > > @@ -22,9 +22,12 @@ import static org.junit.Assert.assertArr
> > >  import static org.junit.Assert.assertEquals;
> > >

Re: [DISCUSS] Brining clirr to the ASF?

[Paul King]

For any Gradle users, Cédric put together a little Gradle plugin based
around the japicmp library which we use in Groovy, see here:

https://github.com/apache/groovy/blob/master/gradle/binarycompatibility.gradle

Cheers, Paul.

On Tue, Jun 14, 2016 at 9:56 PM, James Carman 
wrote:

> +1 to Jochen's idea and I'd love to contribute to that effort!
>
> On Tue, Jun 14, 2016 at 2:40 AM Jochen Wiedmann  >
> wrote:
>
> > On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory 
> > wrote:
> >
> > >> as Jochen has pointed out, Clirr seems to be unmaintained. However we
> > build
> > >> a good part of our release strategy upon clirr. So I wonder whether we
> > >> should foster bringing clirr to the ASF (for example by going through
> > >> incubation). We're probably not the only ASF project using Clirr.
> > >>
> > >
> > > +1. Can we bring in code that's under GNU Lesser General Public and
> make
> > it
> > > ASL 2?
> > >
> > > Could fit under a new Commons Build or Clirr component since it is a
> > > "common" build requirement.
> >
> > As Clirr is internally based on BCEL, I'd rather see us build a new
> > tool on top of ASM, which is very well maintained. Besides, that would
> > solve the license problem.
> >
> > 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
> >
> >
>

Re: [crypto] On Java 6, really?

[Matt Sicker]

I'd prefer to get to 1.7 as soon as possible, but if the API is ready for a
1.0 release already, we could wait for 1.1 or 1.2 before going full 1.7.

On 14 June 2016 at 06:16, Stian Soiland-Reyes  wrote:

> +1 to JDK7 on crypto
> On 14 Jun 2016 10:25 a.m., "Sun, Dapeng"  wrote:
>
> > > Then next release(after 1.0.0) must be a major release you mean?
> > > If there are no potential users looking for JDK 1.6, dropping now
> should
> > be good idea IMO.
> >
> > Thank Uma, I just checked there is no much changes on upgrading JDK to
> > 1.7, I think we can upgrade before this release.
> >
> > Is there anyone have other opinions?
> >
> > Regards
> > Dapeng
> >
> > -Original Message-
> > From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> > Sent: Tuesday, June 14, 2016 4:21 PM
> > To: Commons Developers List
> > Subject: Re: [crypto] On Java 6, really?
> >
> > Then next release(after 1.0.0) must be a major release you mean?
> > If there are no potential users looking for JDK 1.6, dropping now should
> > be good idea IMO.
> >
> > I also remembered that we wanted to mark 1.0.0 release as Alpha right?
> > (just a question)
> >
> > Regards,
> > Uma
> >
> > On 6/14/16, 12:27 AM, "Sun, Dapeng"  wrote:
> >
> > >Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and
> > >Matt for all your input.
> > >
> > >How about make a conservative decision: regarding the first
> > >release(1.0.0), we keep the JDK version as 1.6, and we wouldn't support
> > >JDK 1.6 for the releases after 1.0.0.
> > >
> > >Regards
> > >Dapeng
> > >
> > >-Original Message-
> > >From: Matt Sicker [mailto:boa...@gmail.com]
> > >Sent: Wednesday, June 08, 2016 6:18 AM
> > >To: Commons Developers List
> > >Subject: Re: [crypto] On Java 6, really?
> > >
> > >I'd imagine that close to 100% of users who are on Java 6 are not
> > >upgrading anything else, either, nor would they be adding in new
> > >dependencies. Every Java 6 project I've come across lately has been in
> > >legacy maintenance mode (just like Java 6 itself).
> > >
> > >On 7 June 2016 at 16:47, Gary Gregory  wrote:
> > >
> > >> Let's not forget that customers are paying Oracle to get Java 6
> updates.
> > >>
> > >> Gary
> > >> On Jun 7, 2016 1:24 PM, "Ralph Goers" 
> > >>wrote:
> > >>
> > >> > I really don¹t think the premier & extended support dates should
> > >> > really mean much, except as an indicator of how many users of that
> > >> > version might still exist.  Basically, no new features are going to
> > >> > be added to Java
> > >> so I
> > >> > don¹t think we should be targeting new features there either. If
> > >> > there
> > >> is a
> > >> > bug that needs to be fixed it should be possible to do it on a
> > >> > branch of the the release for that version of Java.  The web site
> > >> > should clearly indicate which versions of the component support the
> > >> > appropriate Java versions.
> > >> >
> > >> > Ralph
> > >> >
> > >> > > On Jun 7, 2016, at 12:26 PM, sebb  wrote:
> > >> > >
> > >> > > I have just checked Oracle support for Java 6.
> > >> > >
> > >> > > The Support Life for Java 6 has been extended to Dec 2018 [1] I
> > >> > > think this means that there are critical systems that cannot yet
> > >> > > be updated to Java 7+.
> > >> > >
> > >> > > This does not mean that we should ensure that all Commons code
> > >> > > still works on Java 6.
> > >> > > But it should be taken into account when evaluating the pros and
> > >> > > cons of requiring a later version.
> > >> > >
> > >> > > [1]
> > >> > > http://www.oracle.com/technetwork/java/eol-135779.html#extended6
> > >> > >
> > >> > > On 7 June 2016 at 20:02, Jochen Wiedmann
> > >> > > 
> > >> > wrote:
> > >> > >>> Gary Gregory  wrote on Tue., 7. Juni
> > >> > >>> 2016
> > >> > >>>
> > >> >  Are we really starting a new component on a dead platform like
> > >> >  Java
> > >> 6?
> > >> > >>
> > >> > >>
> > >> > >> You are, of course, right, that the component is more than
> > >> > >> welcome to use another version. OTOH, given our latest
> > >> > >> experiences: Is this really someting, that we should care for?
> > >> > >> IMO, let the component have, whatever they want.
> > >> > >>
> > >> > >> Jochen
> > >> > >>
> > >> > >> 
> > >> > >> -
> > >> > >>  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: Re: [ALL] About binary compatibility

[Matt Benson]

On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov  wrote:

> I like the way Eclipse it does for years:
>
> 1) Everything inside **/internal/ packages is non API by definition
> 2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published"
> packages
> 3) Javadoc @noextend tag for classes not intended to be extended
> 4) Javadoc @noimplement tag for interfaces
>
> If "real" annotations were used for points 3 and 4, they could live
alongside a Java (6) Processor that, if the user had annotation processing
enabled, could fail the build (pretty sure this is doable).

Matt


> A bonus for libraries with correct MANIFEST.MF is that they can be
> directly used as bundles inside any OSGI container (also Eclipse).
>
> Example:
> /**
>  * An observable value whose changes can be vetoed by listeners.
>  *
>  * @param 
>  *the type of value being observed
>  *
>  * @noextend This interface is not intended to be extended by clients.
>  * @noimplement This interface is not intended to be implemented by
> clients.
>  *  Clients should instead subclass one of the classes that
>  *  implement this interface. Note that direct implementers of
> this
>  *  interface outside of the framework will be broken in future
>  *  releases when methods are added to this interface.
>  *
>  * @since 1.0
>  *
>  */
> public interface IVetoableValue extends IObservableValue {
>
> Kind regards,
> Andrey Loskutov
>
> http://google.com/+AndreyLoskutov
>
>
> > Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> > Von: "Jörg Schaible" 
> > An: dev@commons.apache.org
> > Betreff: Re: [ALL] About binary compatibility
> >
> > Hi,
> >
> > James Carman wrote:
> >
> > > Agree we should have a "source of truth". Is there something wrong with
> > > using an "internal" or "impl" package name? The bundle plugin for OSGi
> > > doesn't export these by default, which would be a nice side effect! :).
> >
> > While it is a step in the right direction, a package scoped solution does
> > not solve the problem of a public interface that should not be
> implemented
> > directly (as we've seen with the BCEL visitor). Time for Java 8 and its
> > default implementations ...
> >
> > Cheers,
> > Jörg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Re: [ALL] About binary compatibility

[Gary Gregory]

On Jun 14, 2016 7:45 AM, "Matt Benson"  wrote:
>
> On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov  wrote:
>
> > I like the way Eclipse it does for years:
> >
> > 1) Everything inside **/internal/ packages is non API by definition
> > 2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published"
> > packages
> > 3) Javadoc @noextend tag for classes not intended to be extended
> > 4) Javadoc @noimplement tag for interfaces
> >
> > If "real" annotations were used for points 3 and 4, they could live
> alongside a Java (6) Processor that, if the user had annotation processing
> enabled, could fail the build (pretty sure this is doable).

But where do these annotations live? Does each Commons component duplicate
them?

Gary
>
> Matt
>
>
> > A bonus for libraries with correct MANIFEST.MF is that they can be
> > directly used as bundles inside any OSGI container (also Eclipse).
> >
> > Example:
> > /**
> >  * An observable value whose changes can be vetoed by listeners.
> >  *
> >  * @param 
> >  *the type of value being observed
> >  *
> >  * @noextend This interface is not intended to be extended by clients.
> >  * @noimplement This interface is not intended to be implemented by
> > clients.
> >  *  Clients should instead subclass one of the classes that
> >  *  implement this interface. Note that direct implementers
of
> > this
> >  *  interface outside of the framework will be broken in
future
> >  *  releases when methods are added to this interface.
> >  *
> >  * @since 1.0
> >  *
> >  */
> > public interface IVetoableValue extends IObservableValue {
> >
> > Kind regards,
> > Andrey Loskutov
> >
> > http://google.com/+AndreyLoskutov
> >
> >
> > > Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> > > Von: "Jörg Schaible" 
> > > An: dev@commons.apache.org
> > > Betreff: Re: [ALL] About binary compatibility
> > >
> > > Hi,
> > >
> > > James Carman wrote:
> > >
> > > > Agree we should have a "source of truth". Is there something wrong
with
> > > > using an "internal" or "impl" package name? The bundle plugin for
OSGi
> > > > doesn't export these by default, which would be a nice side effect!
:).
> > >
> > > While it is a step in the right direction, a package scoped solution
does
> > > not solve the problem of a public interface that should not be
> > implemented
> > > directly (as we've seen with the BCEL visitor). Time for Java 8 and
its
> > > default implementations ...
> > >
> > > Cheers,
> > > Jörg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

Re: [crypto] On Java 6, really?

[Gary Gregory]

On Jun 14, 2016 7:51 AM, "James Carman"  wrote:
>
> The trick is if we want to require a major version upgrade to bump JDK
> levels. That's why you'd want to bump it now if possible.

We've not required major version bumps for Java bumps in the past.

Gary

>
> On Tue, Jun 14, 2016 at 10:41 AM Matt Sicker  wrote:
>
> > I'd prefer to get to 1.7 as soon as possible, but if the API is ready
for a
> > 1.0 release already, we could wait for 1.1 or 1.2 before going full 1.7.
> >
> > On 14 June 2016 at 06:16, Stian Soiland-Reyes  wrote:
> >
> > > +1 to JDK7 on crypto
> > > On 14 Jun 2016 10:25 a.m., "Sun, Dapeng"  wrote:
> > >
> > > > > Then next release(after 1.0.0) must be a major release you mean?
> > > > > If there are no potential users looking for JDK 1.6, dropping now
> > > should
> > > > be good idea IMO.
> > > >
> > > > Thank Uma, I just checked there is no much changes on upgrading JDK
to
> > > > 1.7, I think we can upgrade before this release.
> > > >
> > > > Is there anyone have other opinions?
> > > >
> > > > Regards
> > > > Dapeng
> > > >
> > > > -Original Message-
> > > > From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> > > > Sent: Tuesday, June 14, 2016 4:21 PM
> > > > To: Commons Developers List
> > > > Subject: Re: [crypto] On Java 6, really?
> > > >
> > > > Then next release(after 1.0.0) must be a major release you mean?
> > > > If there are no potential users looking for JDK 1.6, dropping now
> > should
> > > > be good idea IMO.
> > > >
> > > > I also remembered that we wanted to mark 1.0.0 release as Alpha
right?
> > > > (just a question)
> > > >
> > > > Regards,
> > > > Uma
> > > >
> > > > On 6/14/16, 12:27 AM, "Sun, Dapeng"  wrote:
> > > >
> > > > >Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and
> > > > >Matt for all your input.
> > > > >
> > > > >How about make a conservative decision: regarding the first
> > > > >release(1.0.0), we keep the JDK version as 1.6, and we wouldn't
> > support
> > > > >JDK 1.6 for the releases after 1.0.0.
> > > > >
> > > > >Regards
> > > > >Dapeng
> > > > >
> > > > >-Original Message-
> > > > >From: Matt Sicker [mailto:boa...@gmail.com]
> > > > >Sent: Wednesday, June 08, 2016 6:18 AM
> > > > >To: Commons Developers List
> > > > >Subject: Re: [crypto] On Java 6, really?
> > > > >
> > > > >I'd imagine that close to 100% of users who are on Java 6 are not
> > > > >upgrading anything else, either, nor would they be adding in new
> > > > >dependencies. Every Java 6 project I've come across lately has
been in
> > > > >legacy maintenance mode (just like Java 6 itself).
> > > > >
> > > > >On 7 June 2016 at 16:47, Gary Gregory 
wrote:
> > > > >
> > > > >> Let's not forget that customers are paying Oracle to get Java 6
> > > updates.
> > > > >>
> > > > >> Gary
> > > > >> On Jun 7, 2016 1:24 PM, "Ralph Goers" 
> > > > >>wrote:
> > > > >>
> > > > >> > I really don¹t think the premier & extended support dates
should
> > > > >> > really mean much, except as an indicator of how many users of
that
> > > > >> > version might still exist.  Basically, no new features are
going
> > to
> > > > >> > be added to Java
> > > > >> so I
> > > > >> > don¹t think we should be targeting new features there either.
If
> > > > >> > there
> > > > >> is a
> > > > >> > bug that needs to be fixed it should be possible to do it on a
> > > > >> > branch of the the release for that version of Java.  The web
site
> > > > >> > should clearly indicate which versions of the component support
> > the
> > > > >> > appropriate Java versions.
> > > > >> >
> > > > >> > Ralph
> > > > >> >
> > > > >> > > On Jun 7, 2016, at 12:26 PM, sebb  wrote:
> > > > >> > >
> > > > >> > > I have just checked Oracle support for Java 6.
> > > > >> > >
> > > > >> > > The Support Life for Java 6 has been extended to Dec 2018
[1] I
> > > > >> > > think this means that there are critical systems that cannot
yet
> > > > >> > > be updated to Java 7+.
> > > > >> > >
> > > > >> > > This does not mean that we should ensure that all Commons
code
> > > > >> > > still works on Java 6.
> > > > >> > > But it should be taken into account when evaluating the pros
and
> > > > >> > > cons of requiring a later version.
> > > > >> > >
> > > > >> > > [1]
> > > > >> > >
> > http://www.oracle.com/technetwork/java/eol-135779.html#extended6
> > > > >> > >
> > > > >> > > On 7 June 2016 at 20:02, Jochen Wiedmann
> > > > >> > > 
> > > > >> > wrote:
> > > > >> > >>> Gary Gregory  wrote on Tue., 7.
Juni
> > > > >> > >>> 2016
> > > > >> > >>>
> > > > >> >  Are we really starting a new component on a dead platform
> > like
> > > > >> >  Java
> > > > >> 6?
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> You are, of course, right, that the component is more than
> > > > >> > >> welcome to use another version. OTOH, given our latest
> > > > >> > >> experiences: Is this really someting, that we should care
for?
> > > > >> > >> IMO, let the component have, whatever they want.
> > > > >> > >>
> > > > >> > >> Jo

Re: [crypto] On Java 6, really?

[James Carman]

The trick is if we want to require a major version upgrade to bump JDK
levels. That's why you'd want to bump it now if possible.

On Tue, Jun 14, 2016 at 10:41 AM Matt Sicker  wrote:

> I'd prefer to get to 1.7 as soon as possible, but if the API is ready for a
> 1.0 release already, we could wait for 1.1 or 1.2 before going full 1.7.
>
> On 14 June 2016 at 06:16, Stian Soiland-Reyes  wrote:
>
> > +1 to JDK7 on crypto
> > On 14 Jun 2016 10:25 a.m., "Sun, Dapeng"  wrote:
> >
> > > > Then next release(after 1.0.0) must be a major release you mean?
> > > > If there are no potential users looking for JDK 1.6, dropping now
> > should
> > > be good idea IMO.
> > >
> > > Thank Uma, I just checked there is no much changes on upgrading JDK to
> > > 1.7, I think we can upgrade before this release.
> > >
> > > Is there anyone have other opinions?
> > >
> > > Regards
> > > Dapeng
> > >
> > > -Original Message-
> > > From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> > > Sent: Tuesday, June 14, 2016 4:21 PM
> > > To: Commons Developers List
> > > Subject: Re: [crypto] On Java 6, really?
> > >
> > > Then next release(after 1.0.0) must be a major release you mean?
> > > If there are no potential users looking for JDK 1.6, dropping now
> should
> > > be good idea IMO.
> > >
> > > I also remembered that we wanted to mark 1.0.0 release as Alpha right?
> > > (just a question)
> > >
> > > Regards,
> > > Uma
> > >
> > > On 6/14/16, 12:27 AM, "Sun, Dapeng"  wrote:
> > >
> > > >Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and
> > > >Matt for all your input.
> > > >
> > > >How about make a conservative decision: regarding the first
> > > >release(1.0.0), we keep the JDK version as 1.6, and we wouldn't
> support
> > > >JDK 1.6 for the releases after 1.0.0.
> > > >
> > > >Regards
> > > >Dapeng
> > > >
> > > >-Original Message-
> > > >From: Matt Sicker [mailto:boa...@gmail.com]
> > > >Sent: Wednesday, June 08, 2016 6:18 AM
> > > >To: Commons Developers List
> > > >Subject: Re: [crypto] On Java 6, really?
> > > >
> > > >I'd imagine that close to 100% of users who are on Java 6 are not
> > > >upgrading anything else, either, nor would they be adding in new
> > > >dependencies. Every Java 6 project I've come across lately has been in
> > > >legacy maintenance mode (just like Java 6 itself).
> > > >
> > > >On 7 June 2016 at 16:47, Gary Gregory  wrote:
> > > >
> > > >> Let's not forget that customers are paying Oracle to get Java 6
> > updates.
> > > >>
> > > >> Gary
> > > >> On Jun 7, 2016 1:24 PM, "Ralph Goers" 
> > > >>wrote:
> > > >>
> > > >> > I really don¹t think the premier & extended support dates should
> > > >> > really mean much, except as an indicator of how many users of that
> > > >> > version might still exist.  Basically, no new features are going
> to
> > > >> > be added to Java
> > > >> so I
> > > >> > don¹t think we should be targeting new features there either. If
> > > >> > there
> > > >> is a
> > > >> > bug that needs to be fixed it should be possible to do it on a
> > > >> > branch of the the release for that version of Java.  The web site
> > > >> > should clearly indicate which versions of the component support
> the
> > > >> > appropriate Java versions.
> > > >> >
> > > >> > Ralph
> > > >> >
> > > >> > > On Jun 7, 2016, at 12:26 PM, sebb  wrote:
> > > >> > >
> > > >> > > I have just checked Oracle support for Java 6.
> > > >> > >
> > > >> > > The Support Life for Java 6 has been extended to Dec 2018 [1] I
> > > >> > > think this means that there are critical systems that cannot yet
> > > >> > > be updated to Java 7+.
> > > >> > >
> > > >> > > This does not mean that we should ensure that all Commons code
> > > >> > > still works on Java 6.
> > > >> > > But it should be taken into account when evaluating the pros and
> > > >> > > cons of requiring a later version.
> > > >> > >
> > > >> > > [1]
> > > >> > >
> http://www.oracle.com/technetwork/java/eol-135779.html#extended6
> > > >> > >
> > > >> > > On 7 June 2016 at 20:02, Jochen Wiedmann
> > > >> > > 
> > > >> > wrote:
> > > >> > >>> Gary Gregory  wrote on Tue., 7. Juni
> > > >> > >>> 2016
> > > >> > >>>
> > > >> >  Are we really starting a new component on a dead platform
> like
> > > >> >  Java
> > > >> 6?
> > > >> > >>
> > > >> > >>
> > > >> > >> You are, of course, right, that the component is more than
> > > >> > >> welcome to use another version. OTOH, given our latest
> > > >> > >> experiences: Is this really someting, that we should care for?
> > > >> > >> IMO, let the component have, whatever they want.
> > > >> > >>
> > > >> > >> Jochen
> > > >> > >>
> > > >> > >>
> 
> > > >> > >> -
> > > >> > >>  To unsubscribe, e-mail:
> dev-unsubscr...@commons.apache.org
> > > >> > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > > >> > >>
> > > >> > >
> > > >> > >
> -

Re: Re: [ALL] About binary compatibility

[Matt Benson]

On Jun 14, 2016 9:55 AM, "Gary Gregory"  wrote:
>
>
> On Jun 14, 2016 7:45 AM, "Matt Benson"  wrote:
> >
> > On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov 
wrote:
> >
> > > I like the way Eclipse it does for years:
> > >
> > > 1) Everything inside **/internal/ packages is non API by definition
> > > 2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published"
> > > packages
> > > 3) Javadoc @noextend tag for classes not intended to be extended
> > > 4) Javadoc @noimplement tag for interfaces
> > >
> > > If "real" annotations were used for points 3 and 4, they could live
> > alongside a Java (6) Processor that, if the user had annotation
processing
> > enabled, could fail the build (pretty sure this is doable).
>
> But where do these annotations live? Does each Commons component
duplicate them?
>

I thought about that, and would conclude that they should live in a thin
compile-time-only dependency library (it may be the case that usable
versions of these annotations already exist someplace, but the processor
would still have to be provided in this manner, so it doesn't really change
anything). No reason this couldn't be used outside Commons either, actually.

Matt

> Gary
>
> >
> > Matt
> >
> >
> > > A bonus for libraries with correct MANIFEST.MF is that they can be
> > > directly used as bundles inside any OSGI container (also Eclipse).
> > >
> > > Example:
> > > /**
> > >  * An observable value whose changes can be vetoed by listeners.
> > >  *
> > >  * @param 
> > >  *the type of value being observed
> > >  *
> > >  * @noextend This interface is not intended to be extended by clients.
> > >  * @noimplement This interface is not intended to be implemented by
> > > clients.
> > >  *  Clients should instead subclass one of the classes
that
> > >  *  implement this interface. Note that direct
implementers of
> > > this
> > >  *  interface outside of the framework will be broken in
future
> > >  *  releases when methods are added to this interface.
> > >  *
> > >  * @since 1.0
> > >  *
> > >  */
> > > public interface IVetoableValue extends IObservableValue {
> > >
> > > Kind regards,
> > > Andrey Loskutov
> > >
> > > http://google.com/+AndreyLoskutov
> > >
> > >
> > > > Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> > > > Von: "Jörg Schaible" 
> > > > An: dev@commons.apache.org
> > > > Betreff: Re: [ALL] About binary compatibility
> > > >
> > > > Hi,
> > > >
> > > > James Carman wrote:
> > > >
> > > > > Agree we should have a "source of truth". Is there something
wrong with
> > > > > using an "internal" or "impl" package name? The bundle plugin for
OSGi
> > > > > doesn't export these by default, which would be a nice side
effect! :).
> > > >
> > > > While it is a step in the right direction, a package scoped
solution does
> > > > not solve the problem of a public interface that should not be
> > > implemented
> > > > directly (as we've seen with the BCEL visitor). Time for Java 8 and
its
> > > > default implementations ...
> > > >
> > > > Cheers,
> > > > Jörg
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >

Re: Re: [ALL] About binary compatibility

[James Carman]

Perhaps the new ASM-based replacement for CLIRR could have those as one of
its "components" in its TLP?

On Tue, Jun 14, 2016 at 11:00 AM Matt Benson  wrote:

> On Jun 14, 2016 9:55 AM, "Gary Gregory"  wrote:
> >
> >
> > On Jun 14, 2016 7:45 AM, "Matt Benson"  wrote:
> > >
> > > On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov 
> wrote:
> > >
> > > > I like the way Eclipse it does for years:
> > > >
> > > > 1) Everything inside **/internal/ packages is non API by definition
> > > > 2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published"
> > > > packages
> > > > 3) Javadoc @noextend tag for classes not intended to be extended
> > > > 4) Javadoc @noimplement tag for interfaces
> > > >
> > > > If "real" annotations were used for points 3 and 4, they could live
> > > alongside a Java (6) Processor that, if the user had annotation
> processing
> > > enabled, could fail the build (pretty sure this is doable).
> >
> > But where do these annotations live? Does each Commons component
> duplicate them?
> >
>
> I thought about that, and would conclude that they should live in a thin
> compile-time-only dependency library (it may be the case that usable
> versions of these annotations already exist someplace, but the processor
> would still have to be provided in this manner, so it doesn't really change
> anything). No reason this couldn't be used outside Commons either,
> actually.
>
> Matt
>
> > Gary
> >
> > >
> > > Matt
> > >
> > >
> > > > A bonus for libraries with correct MANIFEST.MF is that they can be
> > > > directly used as bundles inside any OSGI container (also Eclipse).
> > > >
> > > > Example:
> > > > /**
> > > >  * An observable value whose changes can be vetoed by listeners.
> > > >  *
> > > >  * @param 
> > > >  *the type of value being observed
> > > >  *
> > > >  * @noextend This interface is not intended to be extended by
> clients.
> > > >  * @noimplement This interface is not intended to be implemented by
> > > > clients.
> > > >  *  Clients should instead subclass one of the classes
> that
> > > >  *  implement this interface. Note that direct
> implementers of
> > > > this
> > > >  *  interface outside of the framework will be broken in
> future
> > > >  *  releases when methods are added to this interface.
> > > >  *
> > > >  * @since 1.0
> > > >  *
> > > >  */
> > > > public interface IVetoableValue extends IObservableValue {
> > > >
> > > > Kind regards,
> > > > Andrey Loskutov
> > > >
> > > > http://google.com/+AndreyLoskutov
> > > >
> > > >
> > > > > Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> > > > > Von: "Jörg Schaible" 
> > > > > An: dev@commons.apache.org
> > > > > Betreff: Re: [ALL] About binary compatibility
> > > > >
> > > > > Hi,
> > > > >
> > > > > James Carman wrote:
> > > > >
> > > > > > Agree we should have a "source of truth". Is there something
> wrong with
> > > > > > using an "internal" or "impl" package name? The bundle plugin for
> OSGi
> > > > > > doesn't export these by default, which would be a nice side
> effect! :).
> > > > >
> > > > > While it is a step in the right direction, a package scoped
> solution does
> > > > > not solve the problem of a public interface that should not be
> > > > implemented
> > > > > directly (as we've seen with the BCEL visitor). Time for Java 8 and
> its
> > > > > default implementations ...
> > > > >
> > > > > Cheers,
> > > > > Jörg
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
>

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

[Gary Gregory]

On Jun 14, 2016 5:19 AM, "James Carman"  wrote:
>
> Are Readers that hard to create?

No, but remembering how to do this is a pain:

 File out = ...

 Charset charset = ...

 CSVPrinter printer = new CSVPrinter(new OutputStreamWriter(new
FileOutputStream(out), charset), format);
Instead of:

format.print(file, charset);

We can roll these two APIs back out and document that the components only
provides low-level APIs, forget convenience APIs.

We can also find a better home for these APIs... like where? On the printer
static side?

Gary

Itv
>
> On Tue, Jun 14, 2016 at 2:17 AM Gary Gregory 
wrote:
>
> > On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter 
> > wrote:
> >
> > > I don't like how we're evolving CSVFormat. It is becoming a dumping
> > ground
> > > for anything that may be useful or convenient. The more methods we
add,
> > the
> > > harder it becomes for users to find the right method for their use
case.
> > >
> >
> > Small is nice, I get that. But how would you do it differently so that I
> > can easily use Paths, Files, URI, and URLs...
> >
> > Gary
> >
> >
> > >
> > > Benedikt
> > >
> > >  schrieb am Di., 14. Juni 2016 um 07:53 Uhr:
> > >
> > > > Author: ggregory
> > > > Date: Tue Jun 14 05:53:32 2016
> > > > New Revision: 1748347
> > > >
> > > > URL: http://svn.apache.org/viewvc?rev=1748347&view=rev
> > > > Log:
> > > > Add convenience API CSVFormat.print(File, Charset) (JIRA is down
ATM).
> > > >
> > > > Modified:
> > > > commons/proper/csv/trunk/src/changes/changes.xml
> > > >
> > > >
> > >
> >
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > >
> > > >
> > >
> >
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > > >
> > > > Modified: commons/proper/csv/trunk/src/changes/changes.xml
> > > > URL:
> > > >
> > >
> >
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/changes/changes.xml?rev=1748347&r1=1748346&r2=1748347&view=diff
> > > >
> > > >
> > >
> >
==
> > > > --- commons/proper/csv/trunk/src/changes/changes.xml (original)
> > > > +++ commons/proper/csv/trunk/src/changes/changes.xml Tue Jun 14
> > 05:53:32
> > > > 2016
> > > > @@ -40,6 +40,7 @@
> > > >
> > > >  
> > > > > due-to="Gary
> > > > Gregory">Update platform requirement from Java 6 to 7.
> > > > +  Add convenience API CSVFormat.print(File, Charset)
> > > >  
> > > >  
> > > > > due-to="Gary
> > > > Gregory">Make CSVPrinter.print(Object) GC-free.
> > > >
> > > > Modified:
> > > >
> > >
> >
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > > URL:
> > > >
> > >
> >
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1748347&r1=1748346&r2=1748347&view=diff
> > > >
> > > >
> > >
> >
==
> > > > ---
> > > >
> > >
> >
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > > (original)
> > > > +++
> > > >
> > >
> >
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > > Tue Jun 14 05:53:32 2016
> > > > @@ -28,10 +28,14 @@ import static org.apache.commons.csv.Con
> > > >  import static org.apache.commons.csv.Constants.SP;
> > > >  import static org.apache.commons.csv.Constants.TAB;
> > > >
> > > > +import java.io.File;
> > > > +import java.io.FileOutputStream;
> > > >  import java.io.IOException;
> > > > +import java.io.OutputStreamWriter;
> > > >  import java.io.Reader;
> > > >  import java.io.Serializable;
> > > >  import java.io.StringWriter;
> > > > +import java.nio.charset.Charset;
> > > >  import java.sql.ResultSet;
> > > >  import java.sql.ResultSetMetaData;
> > > >  import java.sql.SQLException;
> > > > @@ -864,6 +868,27 @@ public final class CSVFormat implements
> > > >  }
> > > >
> > > >  /**
> > > > + * Prints to the specified output.
> > > > + *
> > > > + * 
> > > > + * See also {@link CSVPrinter}.
> > > > + * 
> > > > + *
> > > > + * @param out
> > > > + *the output
> > > > + * @param charset
> > > > + *A charset
> > > > + * @return a printer to an output
> > > > + * @throws IOException
> > > > + * thrown if the optional header cannot be printed.
> > > > + * @since 1.5
> > > > + */
> > > > +public CSVPrinter print(final File out, Charset charset) throws
> > > > IOException {
> > > > +// The FileWriter will be closed when close() is called.
> > > > +return new CSVPrinter(new OutputStreamWriter(new
> > > > FileOutputStream(out), charset), this);
> > > > +}
> > > > +
> > > > +/**
> > > >   * Prints the {@code value} as the next value on the line to
> > {@code
> > > > out}. The value will be escaped or encapsulated
> > > >   * as needed. Useful when one wants to avoid creatin

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

[James Carman]

Can folks perhaps combine commons-io to help?

On Tue, Jun 14, 2016 at 11:27 AM Gary Gregory 
wrote:

> On Jun 14, 2016 5:19 AM, "James Carman" 
> wrote:
> >
> > Are Readers that hard to create?
>
> No, but remembering how to do this is a pain:
>
>  File out = ...
>
>  Charset charset = ...
>
>  CSVPrinter printer = new CSVPrinter(new OutputStreamWriter(new
> FileOutputStream(out), charset), format);
> Instead of:
>
> format.print(file, charset);
>
> We can roll these two APIs back out and document that the components only
> provides low-level APIs, forget convenience APIs.
>
> We can also find a better home for these APIs... like where? On the printer
> static side?
>
> Gary
>
> Itv
> >
> > On Tue, Jun 14, 2016 at 2:17 AM Gary Gregory 
> wrote:
> >
> > > On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter 
> > > wrote:
> > >
> > > > I don't like how we're evolving CSVFormat. It is becoming a dumping
> > > ground
> > > > for anything that may be useful or convenient. The more methods we
> add,
> > > the
> > > > harder it becomes for users to find the right method for their use
> case.
> > > >
> > >
> > > Small is nice, I get that. But how would you do it differently so that
> I
> > > can easily use Paths, Files, URI, and URLs...
> > >
> > > Gary
> > >
> > >
> > > >
> > > > Benedikt
> > > >
> > > >  schrieb am Di., 14. Juni 2016 um 07:53 Uhr:
> > > >
> > > > > Author: ggregory
> > > > > Date: Tue Jun 14 05:53:32 2016
> > > > > New Revision: 1748347
> > > > >
> > > > > URL: http://svn.apache.org/viewvc?rev=1748347&view=rev
> > > > > Log:
> > > > > Add convenience API CSVFormat.print(File, Charset) (JIRA is down
> ATM).
> > > > >
> > > > > Modified:
> > > > > commons/proper/csv/trunk/src/changes/changes.xml
> > > > >
> > > > >
> > > >
> > >
>
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > > >
> > > > >
> > > >
> > >
>
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> > > > >
> > > > > Modified: commons/proper/csv/trunk/src/changes/changes.xml
> > > > > URL:
> > > > >
> > > >
> > >
>
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/changes/changes.xml?rev=1748347&r1=1748346&r2=1748347&view=diff
> > > > >
> > > > >
> > > >
> > >
>
> ==
> > > > > --- commons/proper/csv/trunk/src/changes/changes.xml (original)
> > > > > +++ commons/proper/csv/trunk/src/changes/changes.xml Tue Jun 14
> > > 05:53:32
> > > > > 2016
> > > > > @@ -40,6 +40,7 @@
> > > > >
> > > > >  
> > > > > > > due-to="Gary
> > > > > Gregory">Update platform requirement from Java 6 to 7.
> > > > > +   due-to="Gary
> > > > > Gregory">Add convenience API CSVFormat.print(File,
> Charset)
> > > > >  
> > > > >  
> > > > > > > due-to="Gary
> > > > > Gregory">Make CSVPrinter.print(Object) GC-free.
> > > > >
> > > > > Modified:
> > > > >
> > > >
> > >
>
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > > > URL:
> > > > >
> > > >
> > >
>
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1748347&r1=1748346&r2=1748347&view=diff
> > > > >
> > > > >
> > > >
> > >
>
> ==
> > > > > ---
> > > > >
> > > >
> > >
>
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > > > (original)
> > > > > +++
> > > > >
> > > >
> > >
>
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> > > > > Tue Jun 14 05:53:32 2016
> > > > > @@ -28,10 +28,14 @@ import static org.apache.commons.csv.Con
> > > > >  import static org.apache.commons.csv.Constants.SP;
> > > > >  import static org.apache.commons.csv.Constants.TAB;
> > > > >
> > > > > +import java.io.File;
> > > > > +import java.io.FileOutputStream;
> > > > >  import java.io.IOException;
> > > > > +import java.io.OutputStreamWriter;
> > > > >  import java.io.Reader;
> > > > >  import java.io.Serializable;
> > > > >  import java.io.StringWriter;
> > > > > +import java.nio.charset.Charset;
> > > > >  import java.sql.ResultSet;
> > > > >  import java.sql.ResultSetMetaData;
> > > > >  import java.sql.SQLException;
> > > > > @@ -864,6 +868,27 @@ public final class CSVFormat implements
> > > > >  }
> > > > >
> > > > >  /**
> > > > > + * Prints to the specified output.
> > > > > + *
> > > > > + * 
> > > > > + * See also {@link CSVPrinter}.
> > > > > + * 
> > > > > + *
> > > > > + * @param out
> > > > > + *the output
> > > > > + * @param charset
> > > > > + *A charset
> > > > > + * @return a printer to an output
> > > > > + * @throws IOException
> > > > > + * thrown if the optional header cannot be
> printed.
> > > > > + * @since 1.5
> > > > > + */
> > > > > +public CSVPrinter print(final File out, Ch

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

[sebb]

On 14 June 2016 at 16:27, Gary Gregory  wrote:
> On Jun 14, 2016 5:19 AM, "James Carman"  wrote:
>>
>> Are Readers that hard to create?
>
> No, but remembering how to do this is a pain:
>
>  File out = ...
>
>  Charset charset = ...
>
>  CSVPrinter printer = new CSVPrinter(new OutputStreamWriter(new
> FileOutputStream(out), charset), format);
> Instead of:
>
> format.print(file, charset);
>
> We can roll these two APIs back out and document that the components only
> provides low-level APIs, forget convenience APIs.
>
> We can also find a better home for these APIs... like where? On the printer
> static side?

Commons IO

> Gary
>
> Itv
>>
>> On Tue, Jun 14, 2016 at 2:17 AM Gary Gregory 
> wrote:
>>
>> > On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter 
>> > wrote:
>> >
>> > > I don't like how we're evolving CSVFormat. It is becoming a dumping
>> > ground
>> > > for anything that may be useful or convenient. The more methods we
> add,
>> > the
>> > > harder it becomes for users to find the right method for their use
> case.
>> > >
>> >
>> > Small is nice, I get that. But how would you do it differently so that I
>> > can easily use Paths, Files, URI, and URLs...
>> >
>> > Gary
>> >
>> >
>> > >
>> > > Benedikt
>> > >
>> > >  schrieb am Di., 14. Juni 2016 um 07:53 Uhr:
>> > >
>> > > > Author: ggregory
>> > > > Date: Tue Jun 14 05:53:32 2016
>> > > > New Revision: 1748347
>> > > >
>> > > > URL: http://svn.apache.org/viewvc?rev=1748347&view=rev
>> > > > Log:
>> > > > Add convenience API CSVFormat.print(File, Charset) (JIRA is down
> ATM).
>> > > >
>> > > > Modified:
>> > > > commons/proper/csv/trunk/src/changes/changes.xml
>> > > >
>> > > >
>> > >
>> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>> > > >
>> > > >
>> > >
>> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
>> > > >
>> > > > Modified: commons/proper/csv/trunk/src/changes/changes.xml
>> > > > URL:
>> > > >
>> > >
>> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/changes/changes.xml?rev=1748347&r1=1748346&r2=1748347&view=diff
>> > > >
>> > > >
>> > >
>> >
> ==
>> > > > --- commons/proper/csv/trunk/src/changes/changes.xml (original)
>> > > > +++ commons/proper/csv/trunk/src/changes/changes.xml Tue Jun 14
>> > 05:53:32
>> > > > 2016
>> > > > @@ -40,6 +40,7 @@
>> > > >
>> > > >  
>> > > >> > due-to="Gary
>> > > > Gregory">Update platform requirement from Java 6 to 7.
>> > > > +   due-to="Gary
>> > > > Gregory">Add convenience API CSVFormat.print(File, Charset)
>> > > >  
>> > > >  
>> > > >> > due-to="Gary
>> > > > Gregory">Make CSVPrinter.print(Object) GC-free.
>> > > >
>> > > > Modified:
>> > > >
>> > >
>> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>> > > > URL:
>> > > >
>> > >
>> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1748347&r1=1748346&r2=1748347&view=diff
>> > > >
>> > > >
>> > >
>> >
> ==
>> > > > ---
>> > > >
>> > >
>> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>> > > > (original)
>> > > > +++
>> > > >
>> > >
>> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>> > > > Tue Jun 14 05:53:32 2016
>> > > > @@ -28,10 +28,14 @@ import static org.apache.commons.csv.Con
>> > > >  import static org.apache.commons.csv.Constants.SP;
>> > > >  import static org.apache.commons.csv.Constants.TAB;
>> > > >
>> > > > +import java.io.File;
>> > > > +import java.io.FileOutputStream;
>> > > >  import java.io.IOException;
>> > > > +import java.io.OutputStreamWriter;
>> > > >  import java.io.Reader;
>> > > >  import java.io.Serializable;
>> > > >  import java.io.StringWriter;
>> > > > +import java.nio.charset.Charset;
>> > > >  import java.sql.ResultSet;
>> > > >  import java.sql.ResultSetMetaData;
>> > > >  import java.sql.SQLException;
>> > > > @@ -864,6 +868,27 @@ public final class CSVFormat implements
>> > > >  }
>> > > >
>> > > >  /**
>> > > > + * Prints to the specified output.
>> > > > + *
>> > > > + * 
>> > > > + * See also {@link CSVPrinter}.
>> > > > + * 
>> > > > + *
>> > > > + * @param out
>> > > > + *the output
>> > > > + * @param charset
>> > > > + *A charset
>> > > > + * @return a printer to an output
>> > > > + * @throws IOException
>> > > > + * thrown if the optional header cannot be printed.
>> > > > + * @since 1.5
>> > > > + */
>> > > > +public CSVPrinter print(final File out, Charset charset) throws
>> > > > IOException {
>> > > > +// The FileWriter will be closed when close() is called.
>> > > > +return new CSVPrinter(new OutputStreamWriter(new
>> > > > Fil

RE: [BCEL] Release Candidate on Thursday

[Mark Roberts]

I can tell you right now I would vote -1 as you have not picked up the fix for 
https://issues.apache.org/jira/browse/BCEL-243.

Also, I think https://issues.apache.org/jira/browse/BCEL-195 is fixed, but has 
not been closed.


Thank you,
Mark Roberts

> -Original Message-
> From: Benedikt Ritter [mailto:brit...@apache.org]
> Sent: Monday, June 13, 2016 11:49 PM
> To: Commons Developers List
> Subject: [BCEL] Release Candidate on Thursday
> 
> Hi,
> 
> I'm going to try to create an RC for BCEL 6.0 on friday. Please have a look at
> the current state of the code base and report any issues you see.
> 
> Thank you!
> Benedikt


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

Re: [BCEL] Release Candidate on Thursday

[James Carman]

Are they show stoppers?

On Tue, Jun 14, 2016 at 11:50 AM Mark Roberts 
wrote:

> I can tell you right now I would vote -1 as you have not picked up the fix
> for https://issues.apache.org/jira/browse/BCEL-243.
>
> Also, I think https://issues.apache.org/jira/browse/BCEL-195 is fixed,
> but has not been closed.
>
>
> Thank you,
> Mark Roberts
>
> > -Original Message-
> > From: Benedikt Ritter [mailto:brit...@apache.org]
> > Sent: Monday, June 13, 2016 11:49 PM
> > To: Commons Developers List
> > Subject: [BCEL] Release Candidate on Thursday
> >
> > Hi,
> >
> > I'm going to try to create an RC for BCEL 6.0 on friday. Please have a
> look at
> > the current state of the code base and report any issues you see.
> >
> > Thank you!
> > Benedikt
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [BCEL] Release Candidate on Thursday

[Benedikt Ritter]

Hello Mark,

thank you for pointing this out. Saves me a lot of time :-)
I will have a look when Jira is reachable again.

Benedikt

Mark Roberts  schrieb am Di., 14. Juni 2016 um
17:50:

> I can tell you right now I would vote -1 as you have not picked up the fix
> for https://issues.apache.org/jira/browse/BCEL-243.
>
> Also, I think https://issues.apache.org/jira/browse/BCEL-195 is fixed,
> but has not been closed.
>
>
> Thank you,
> Mark Roberts
>
> > -Original Message-
> > From: Benedikt Ritter [mailto:brit...@apache.org]
> > Sent: Monday, June 13, 2016 11:49 PM
> > To: Commons Developers List
> > Subject: [BCEL] Release Candidate on Thursday
> >
> > Hi,
> >
> > I'm going to try to create an RC for BCEL 6.0 on friday. Please have a
> look at
> > the current state of the code base and report any issues you see.
> >
> > Thank you!
> > Benedikt
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

RE: [BCEL] Release Candidate on Thursday

[Mark Roberts]

243 is a show stopper for Daikon.  It will continue to be shipped with our 
private version of BCEL if it is not fixed.

> -Original Message-
> From: James Carman [mailto:ja...@carmanconsulting.com]
> Sent: Tuesday, June 14, 2016 8:51 AM
> To: Commons Developers List
> Subject: Re: [BCEL] Release Candidate on Thursday
> 
> Are they show stoppers?
> 
> On Tue, Jun 14, 2016 at 11:50 AM Mark Roberts
> 
> wrote:
> 
> > I can tell you right now I would vote -1 as you have not picked up the
> > fix for https://issues.apache.org/jira/browse/BCEL-243.
> >
> > Also, I think https://issues.apache.org/jira/browse/BCEL-195 is fixed,
> > but has not been closed.
> >
> >
> > Thank you,
> > Mark Roberts
> >
> > > -Original Message-
> > > From: Benedikt Ritter [mailto:brit...@apache.org]
> > > Sent: Monday, June 13, 2016 11:49 PM
> > > To: Commons Developers List
> > > Subject: [BCEL] Release Candidate on Thursday
> > >
> > > Hi,
> > >
> > > I'm going to try to create an RC for BCEL 6.0 on friday. Please have
> > > a
> > look at
> > > the current state of the code base and report any issues you see.
> > >
> > > Thank you!
> > > 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] Release Candidate on Thursday

[James Carman]

Is it not a showstopper for BCEL itself, though. Do we have a solution to
these two issues readily available? Is it something that we need to noodle
about for a little while and maybe we can just get a release out while we
do that?

On Tue, Jun 14, 2016 at 12:04 PM Mark Roberts 
wrote:

> 243 is a show stopper for Daikon.  It will continue to be shipped with our
> private version of BCEL if it is not fixed.
>
> > -Original Message-
> > From: James Carman [mailto:ja...@carmanconsulting.com]
> > Sent: Tuesday, June 14, 2016 8:51 AM
> > To: Commons Developers List
> > Subject: Re: [BCEL] Release Candidate on Thursday
> >
> > Are they show stoppers?
> >
> > On Tue, Jun 14, 2016 at 11:50 AM Mark Roberts
> > 
> > wrote:
> >
> > > I can tell you right now I would vote -1 as you have not picked up the
> > > fix for https://issues.apache.org/jira/browse/BCEL-243.
> > >
> > > Also, I think https://issues.apache.org/jira/browse/BCEL-195 is fixed,
> > > but has not been closed.
> > >
> > >
> > > Thank you,
> > > Mark Roberts
> > >
> > > > -Original Message-
> > > > From: Benedikt Ritter [mailto:brit...@apache.org]
> > > > Sent: Monday, June 13, 2016 11:49 PM
> > > > To: Commons Developers List
> > > > Subject: [BCEL] Release Candidate on Thursday
> > > >
> > > > Hi,
> > > >
> > > > I'm going to try to create an RC for BCEL 6.0 on friday. Please have
> > > > a
> > > look at
> > > > the current state of the code base and report any issues you see.
> > > >
> > > > Thank you!
> > > > 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] Release Candidate on Thursday

[Andrey Loskutov]

1) You mentioned "private Daikon" build. Can you propose a patch?
2) The bcel-243 reads as an enhancement (some functionality from 1.8 is 
missing). Is this true? Are there any regressions or any errors which can be 
demonstrated with current trunk state? It would be nice to add this info to 
Jira task. 


Am 14. Juni 2016 18:04:24 MESZ, schrieb Mark Roberts :
>243 is a show stopper for Daikon.  It will continue to be shipped with
>our private version of BCEL if it is not fixed.
>
>> -Original Message-
>> From: James Carman [mailto:ja...@carmanconsulting.com]
>> Sent: Tuesday, June 14, 2016 8:51 AM
>> To: Commons Developers List
>> Subject: Re: [BCEL] Release Candidate on Thursday
>> 
>> Are they show stoppers?
>> 
>> On Tue, Jun 14, 2016 at 11:50 AM Mark Roberts
>> 
>> wrote:
>> 
>> > I can tell you right now I would vote -1 as you have not picked up
>the
>> > fix for https://issues.apache.org/jira/browse/BCEL-243.
>> >
>> > Also, I think https://issues.apache.org/jira/browse/BCEL-195 is
>fixed,
>> > but has not been closed.
>> >
>> >
>> > Thank you,
>> > Mark Roberts
>> >
>> > > -Original Message-
>> > > From: Benedikt Ritter [mailto:brit...@apache.org]
>> > > Sent: Monday, June 13, 2016 11:49 PM
>> > > To: Commons Developers List
>> > > Subject: [BCEL] Release Candidate on Thursday
>> > >
>> > > Hi,
>> > >
>> > > I'm going to try to create an RC for BCEL 6.0 on friday. Please
>have
>> > > a
>> > look at
>> > > the current state of the code base and report any issues you see.
>> > >
>> > > Thank you!
>> > > 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

--
Kind regards,
Andrey Loskutov

http://google.com/+AndreyLoskutov

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

RE: [BCEL] Release Candidate on Thursday

[Mark Roberts]

People, please look at the data base before you post.   There has been a fix 
available since August of last year.   (Shortly before the last effort to 
produce a 6.0 pooped out.)  There is also a test case that demonstrates the 
problem.

> -Original Message-
> From: Andrey Loskutov [mailto:losku...@gmx.de]
> Sent: Tuesday, June 14, 2016 9:27 AM
> To: Commons Developers List; Mark Roberts; 'Commons Developers List'
> Subject: RE: [BCEL] Release Candidate on Thursday
> 
> 1) You mentioned "private Daikon" build. Can you propose a patch?
> 2) The bcel-243 reads as an enhancement (some functionality from 1.8 is
> missing). Is this true? Are there any regressions or any errors which can be
> demonstrated with current trunk state? It would be nice to add this info to
> Jira task.
> 
> 
> Am 14. Juni 2016 18:04:24 MESZ, schrieb Mark Roberts
> :
> >243 is a show stopper for Daikon.  It will continue to be shipped with
> >our private version of BCEL if it is not fixed.
> >
> >> -Original Message-
> >> From: James Carman [mailto:ja...@carmanconsulting.com]
> >> Sent: Tuesday, June 14, 2016 8:51 AM
> >> To: Commons Developers List
> >> Subject: Re: [BCEL] Release Candidate on Thursday
> >>
> >> Are they show stoppers?
> >>
> >> On Tue, Jun 14, 2016 at 11:50 AM Mark Roberts
> >> 
> >> wrote:
> >>
> >> > I can tell you right now I would vote -1 as you have not picked up
> >the
> >> > fix for https://issues.apache.org/jira/browse/BCEL-243.
> >> >
> >> > Also, I think https://issues.apache.org/jira/browse/BCEL-195 is
> >fixed,
> >> > but has not been closed.
> >> >
> >> >
> >> > Thank you,
> >> > Mark Roberts
> >> >
> >> > > -Original Message-
> >> > > From: Benedikt Ritter [mailto:brit...@apache.org]
> >> > > Sent: Monday, June 13, 2016 11:49 PM
> >> > > To: Commons Developers List
> >> > > Subject: [BCEL] Release Candidate on Thursday
> >> > >
> >> > > Hi,
> >> > >
> >> > > I'm going to try to create an RC for BCEL 6.0 on friday. Please
> >have
> >> > > a
> >> > look at
> >> > > the current state of the code base and report any issues you see.
> >> > >
> >> > > Thank you!
> >> > > 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
> 
> --
> Kind regards,
> Andrey Loskutov
> 
> http://google.com/+AndreyLoskutov


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

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

[Benedikt Ritter]

How about something like:

on CSVFormat:
public PrintingOps print()

And the PrintingOps class would implement all the different printing
methods, combining the CSVFormat and a printer. The call would look like:

CSVFormat.EXCEL.print().contentsOf(file, StandardCharsets.UTF_8)

sebb  schrieb am Di., 14. Juni 2016 um 17:48 Uhr:

> On 14 June 2016 at 16:27, Gary Gregory  wrote:
> > On Jun 14, 2016 5:19 AM, "James Carman" 
> wrote:
> >>
> >> Are Readers that hard to create?
> >
> > No, but remembering how to do this is a pain:
> >
> >  File out = ...
> >
> >  Charset charset = ...
> >
> >  CSVPrinter printer = new CSVPrinter(new OutputStreamWriter(new
> > FileOutputStream(out), charset), format);
> > Instead of:
> >
> > format.print(file, charset);
> >
> > We can roll these two APIs back out and document that the components only
> > provides low-level APIs, forget convenience APIs.
> >
> > We can also find a better home for these APIs... like where? On the
> printer
> > static side?
>
> Commons IO
>
> > Gary
> >
> > Itv
> >>
> >> On Tue, Jun 14, 2016 at 2:17 AM Gary Gregory 
> > wrote:
> >>
> >> > On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter  >
> >> > wrote:
> >> >
> >> > > I don't like how we're evolving CSVFormat. It is becoming a dumping
> >> > ground
> >> > > for anything that may be useful or convenient. The more methods we
> > add,
> >> > the
> >> > > harder it becomes for users to find the right method for their use
> > case.
> >> > >
> >> >
> >> > Small is nice, I get that. But how would you do it differently so
> that I
> >> > can easily use Paths, Files, URI, and URLs...
> >> >
> >> > Gary
> >> >
> >> >
> >> > >
> >> > > Benedikt
> >> > >
> >> > >  schrieb am Di., 14. Juni 2016 um 07:53 Uhr:
> >> > >
> >> > > > Author: ggregory
> >> > > > Date: Tue Jun 14 05:53:32 2016
> >> > > > New Revision: 1748347
> >> > > >
> >> > > > URL: http://svn.apache.org/viewvc?rev=1748347&view=rev
> >> > > > Log:
> >> > > > Add convenience API CSVFormat.print(File, Charset) (JIRA is down
> > ATM).
> >> > > >
> >> > > > Modified:
> >> > > > commons/proper/csv/trunk/src/changes/changes.xml
> >> > > >
> >> > > >
> >> > >
> >> >
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> >> > > >
> >> > > >
> >> > >
> >> >
> >
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
> >> > > >
> >> > > > Modified: commons/proper/csv/trunk/src/changes/changes.xml
> >> > > > URL:
> >> > > >
> >> > >
> >> >
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/changes/changes.xml?rev=1748347&r1=1748346&r2=1748347&view=diff
> >> > > >
> >> > > >
> >> > >
> >> >
> >
> ==
> >> > > > --- commons/proper/csv/trunk/src/changes/changes.xml (original)
> >> > > > +++ commons/proper/csv/trunk/src/changes/changes.xml Tue Jun 14
> >> > 05:53:32
> >> > > > 2016
> >> > > > @@ -40,6 +40,7 @@
> >> > > >
> >> > > >  
> >> > > > >> > due-to="Gary
> >> > > > Gregory">Update platform requirement from Java 6 to 7.
> >> > > > +   > due-to="Gary
> >> > > > Gregory">Add convenience API CSVFormat.print(File,
> Charset)
> >> > > >  
> >> > > >  
> >> > > > >> > due-to="Gary
> >> > > > Gregory">Make CSVPrinter.print(Object) GC-free.
> >> > > >
> >> > > > Modified:
> >> > > >
> >> > >
> >> >
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> >> > > > URL:
> >> > > >
> >> > >
> >> >
> >
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1748347&r1=1748346&r2=1748347&view=diff
> >> > > >
> >> > > >
> >> > >
> >> >
> >
> ==
> >> > > > ---
> >> > > >
> >> > >
> >> >
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> >> > > > (original)
> >> > > > +++
> >> > > >
> >> > >
> >> >
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
> >> > > > Tue Jun 14 05:53:32 2016
> >> > > > @@ -28,10 +28,14 @@ import static org.apache.commons.csv.Con
> >> > > >  import static org.apache.commons.csv.Constants.SP;
> >> > > >  import static org.apache.commons.csv.Constants.TAB;
> >> > > >
> >> > > > +import java.io.File;
> >> > > > +import java.io.FileOutputStream;
> >> > > >  import java.io.IOException;
> >> > > > +import java.io.OutputStreamWriter;
> >> > > >  import java.io.Reader;
> >> > > >  import java.io.Serializable;
> >> > > >  import java.io.StringWriter;
> >> > > > +import java.nio.charset.Charset;
> >> > > >  import java.sql.ResultSet;
> >> > > >  import java.sql.ResultSetMetaData;
> >> > > >  import java.sql.SQLException;
> >> > > > @@ -864,6 +868,27 @@ public final class CSVFormat implements
> >> > > >  }
> >> > > >
> >> > > >  /**
> >> > > > + * Prints to the specified output.
> >> > > > + *
> >> > > > + * 
> >> > > > +  

Re: [ALL] Volunteers for a Math IPMC?

[Niclas Hedhman]

If you have a functioning community around Commons Math already, why do you
feel you need Incubation?

People on a Math TLP would come out of the Commons PMC and simply submit a
Board Resolution, and I doubt that there would be any objects. There are no
legal concerns, no community training, no need for release management
training, and so on...

Or are you looking at a situation where the Commons community has no
interest in Math subproject, and need new blood?


Cheers
Niclas

On Sat, Jun 11, 2016 at 6:25 PM, James Carman 
wrote:

> We (the Commons PMC) have not decided yet what to do, but I just wanted to
> gauge the interest in joining the math IPMC if we choose to go TLP by way
> of the incubator. The idea would be that math (whatever its name may be),
> would go through the incubator in order to enrich its community prior to
> becoming a TLP. Do we have any folks willing to throw their hat in the
> ring?
>
> p.s. I've cross-posted to the incubator list as there are folks there who
> are very good at this stuff and could perhaps lend us some advice.
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

RE: [DISCUSS] Brining clirr to the ASF?

[Dennis E. Hamilton]

[Chiming in lest those on the Commons PMC who know the answer don't and leave 
the LGPL question dangling.]

> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Monday, June 13, 2016 23:23
> To: Commons Developers List 
> Subject: Re: [DISCUSS] Brining clirr to the ASF?
> 
> On Mon, Jun 13, 2016 at 11:19 PM, Benedikt Ritter 
> wrote:
> 
> > Hi,
> >
> > as Jochen has pointed out, Clirr seems to be unmaintained. However we
> build
> > a good part of our release strategy upon clirr. So I wonder whether we
> > should foster bringing clirr to the ASF (for example by going through
> > incubation). We're probably not the only ASF project using Clirr.
> >
> 
> +1. Can we bring in code that's under GNU Lesser General Public and make
> it
> ASL 2?
[orcmid] 

Short answer: No.

Does not the exception for build dependencies apply for clirr though, so long 
as it is not in releases and in the project repository?  

TL;DR Longer answer, to bring clirr into the project.  If those who hold 
copyright in the Clirr code agree to license it to the ASF under terms that 
empower the ASF to provide a different license, this would work.  It is not 
otherwise possible for parties who are not the original copyright holders or 
so-empowered licensees to alter the license on anything (and that applies to 
ASLv2-licensed works too).  Generally, one can't even get *into* incubation 
without a cure in hand before the subject code is imported for IP cleanup.  
Please consult 
, 
, 
and  for related considerations.

And then there are the dependencies of clirr to pay attention to.

> 
> Could fit under a new Commons Build or Clirr component since it is a
> "common" build requirement.
> 
> Gary
> 
> 
> > Benedikt
> >
> 
> 
> 
> --
> 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: [ALL] Volunteers for a Math IPMC?

[Ralph Goers]

I thought this had been made clear.  Several months Commons voted to make Math 
a TLP. But shortly after that most of the people involved with Commons Math 
felt that a TLP at the ASF would not work for them, so they forked the project 
and left, effectively voiding the TLP vote since the proposed PMC is no longer 
valid.  There is one person left who was very involved in Commons Math and a 
few other people who have expressed interest in joining the new community.  

So this is a situation where we have an already existing code base where a lot 
of the people left are not familiar with quite a bit of it.  The new group of 
people who are interested are trying to determine how they should move forward. 
There is some talk of breaking Commons Math into smaller components and 
possibly dropping some where there is no one to maintain it.  

Ralph

> On Jun 11, 2016, at 6:21 PM, Niclas Hedhman  wrote:
> 
> If you have a functioning community around Commons Math already, why do you
> feel you need Incubation?
> 
> People on a Math TLP would come out of the Commons PMC and simply submit a
> Board Resolution, and I doubt that there would be any objects. There are no
> legal concerns, no community training, no need for release management
> training, and so on...
> 
> Or are you looking at a situation where the Commons community has no
> interest in Math subproject, and need new blood?
> 
> 
> Cheers
> Niclas
> 
> On Sat, Jun 11, 2016 at 6:25 PM, James Carman 
> wrote:
> 
>> We (the Commons PMC) have not decided yet what to do, but I just wanted to
>> gauge the interest in joining the math IPMC if we choose to go TLP by way
>> of the incubator. The idea would be that math (whatever its name may be),
>> would go through the incubator in order to enrich its community prior to
>> becoming a TLP. Do we have any folks willing to throw their hat in the
>> ring?
>> 
>> p.s. I've cross-posted to the incubator list as there are folks there who
>> are very good at this stuff and could perhaps lend us some advice.
>> 
> 
> 
> 
> -- 
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java



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

Re: [DISCUSS] Brining clirr to the ASF?

[Benedikt Ritter]

Thank you for the clarification, Dennis!

Dennis E. Hamilton  schrieb am Di., 14. Juni 2016
um 19:57:

> [Chiming in lest those on the Commons PMC who know the answer don't and
> leave the LGPL question dangling.]
>
> > -Original Message-
> > From: Gary Gregory [mailto:garydgreg...@gmail.com]
> > Sent: Monday, June 13, 2016 23:23
> > To: Commons Developers List 
> > Subject: Re: [DISCUSS] Brining clirr to the ASF?
> >
> > On Mon, Jun 13, 2016 at 11:19 PM, Benedikt Ritter 
> > wrote:
> >
> > > Hi,
> > >
> > > as Jochen has pointed out, Clirr seems to be unmaintained. However we
> > build
> > > a good part of our release strategy upon clirr. So I wonder whether we
> > > should foster bringing clirr to the ASF (for example by going through
> > > incubation). We're probably not the only ASF project using Clirr.
> > >
> >
> > +1. Can we bring in code that's under GNU Lesser General Public and make
> > it
> > ASL 2?
> [orcmid]
>
> Short answer: No.
>
> Does not the exception for build dependencies apply for clirr though, so
> long as it is not in releases and in the project repository?
>
> TL;DR Longer answer, to bring clirr into the project.  If those who hold
> copyright in the Clirr code agree to license it to the ASF under terms that
> empower the ASF to provide a different license, this would work.  It is not
> otherwise possible for parties who are not the original copyright holders
> or so-empowered licensees to alter the license on anything (and that
> applies to ASLv2-licensed works too).  Generally, one can't even get *into*
> incubation without a cure in hand before the subject code is imported for
> IP cleanup.  Please consult
> ,
> ,
> and  for related
> considerations.
>
> And then there are the dependencies of clirr to pay attention to.
>
> >
> > Could fit under a new Commons Build or Clirr component since it is a
> > "common" build requirement.
> >
> > Gary
> >
> >
> > > Benedikt
> > >
> >
> >
> >
> > --
> > 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: [ALL] Volunteers for a Math IPMC?

[Ted Dunning]

Looking back through the discussion, it is a bit of a problem that one of
the major reasons given for the fork is that the team thought that they
didn't have a large enough PMC and that incubation wouldn't get them enough
additional contributors. That made it seem like the project should go
forward without meeting Apache requirements (i.e. outside).

Is the situation really that different now that a vastly diminished team is
likely to benefit from incubation enough to form a viable TLP?

(I hate that this sounds negative ... it is a real question)



On Tue, Jun 14, 2016 at 11:01 AM, Ralph Goers 
wrote:

> I thought this had been made clear.  Several months Commons voted to make
> Math a TLP. But shortly after that most of the people involved with Commons
> Math felt that a TLP at the ASF would not work for them, so they forked the
> project and left, effectively voiding the TLP vote since the proposed PMC
> is no longer valid.  There is one person left who was very involved in
> Commons Math and a few other people who have expressed interest in joining
> the new community.
>
> So this is a situation where we have an already existing code base where a
> lot of the people left are not familiar with quite a bit of it.  The new
> group of people who are interested are trying to determine how they should
> move forward. There is some talk of breaking Commons Math into smaller
> components and possibly dropping some where there is no one to maintain it.
>
> Ralph
>
> > On Jun 11, 2016, at 6:21 PM, Niclas Hedhman  wrote:
> >
> > If you have a functioning community around Commons Math already, why do
> you
> > feel you need Incubation?
> >
> > People on a Math TLP would come out of the Commons PMC and simply submit
> a
> > Board Resolution, and I doubt that there would be any objects. There are
> no
> > legal concerns, no community training, no need for release management
> > training, and so on...
> >
> > Or are you looking at a situation where the Commons community has no
> > interest in Math subproject, and need new blood?
> >
> >
> > Cheers
> > Niclas
> >
> > On Sat, Jun 11, 2016 at 6:25 PM, James Carman <
> ja...@carmanconsulting.com>
> > wrote:
> >
> >> We (the Commons PMC) have not decided yet what to do, but I just wanted
> to
> >> gauge the interest in joining the math IPMC if we choose to go TLP by
> way
> >> of the incubator. The idea would be that math (whatever its name may
> be),
> >> would go through the incubator in order to enrich its community prior to
> >> becoming a TLP. Do we have any folks willing to throw their hat in the
> >> ring?
> >>
> >> p.s. I've cross-posted to the incubator list as there are folks there
> who
> >> are very good at this stuff and could perhaps lend us some advice.
> >>
> >
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://zest.apache.org - New Energy for Java
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [ALL] Volunteers for a Math IPMC?

[Jochen Wiedmann]

On Tue, Jun 14, 2016 at 8:54 PM, Ted Dunning  wrote:
> Looking back through the discussion, it is a bit of a problem that one of
> the major reasons given for the fork is that the team thought that they
> didn't have a large enough PMC and that incubation wouldn't get them enough
> additional contributors. That made it seem like the project should go
> forward without meeting Apache requirements (i.e. outside).
>
> Is the situation really that different now that a vastly diminished team is
> likely to benefit from incubation enough to form a viable TLP?
>
> (I hate that this sounds negative ... it is a real question)

We can't tell you. It is just, that some of us (including me) have the
feeling/opinion, that going through the Incubator is the path, where
the chances are best to attract new committers.

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

Re: [ALL] Volunteers for a Math IPMC?

[Jochen Wiedmann]

On Sat, Jun 11, 2016 at 12:25 PM, James Carman
 wrote:
> We (the Commons PMC) have not decided yet what to do, but I just wanted to
> gauge the interest in joining the math IPMC if we choose to go TLP by way
> of the incubator. The idea would be that math (whatever its name may be),
> would go through the incubator in order to enrich its community prior to
> becoming a TLP. Do we have any folks willing to throw their hat in the ring?
>
> p.s. I've cross-posted to the incubator list as there are folks there who
> are very good at this stuff and could perhaps lend us some advice.

As I already wrote elsewhere: I could (and would) put an IPMC hat on.
(And a mentors hat as well.)


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

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

[Oliver Heger]

Just as an info, [configuration] has a similar problem. There is a
FileHandler class (in the io subpackage) which allows defining a target
file in various ways and does the conversion to streams.

Oliver

Am 14.06.2016 um 18:33 schrieb Benedikt Ritter:
> How about something like:
> 
> on CSVFormat:
> public PrintingOps print()
> 
> And the PrintingOps class would implement all the different printing
> methods, combining the CSVFormat and a printer. The call would look like:
> 
> CSVFormat.EXCEL.print().contentsOf(file, StandardCharsets.UTF_8)
> 
> sebb  schrieb am Di., 14. Juni 2016 um 17:48 Uhr:
> 
>> On 14 June 2016 at 16:27, Gary Gregory  wrote:
>>> On Jun 14, 2016 5:19 AM, "James Carman" 
>> wrote:

 Are Readers that hard to create?
>>>
>>> No, but remembering how to do this is a pain:
>>>
>>>  File out = ...
>>>
>>>  Charset charset = ...
>>>
>>>  CSVPrinter printer = new CSVPrinter(new OutputStreamWriter(new
>>> FileOutputStream(out), charset), format);
>>> Instead of:
>>>
>>> format.print(file, charset);
>>>
>>> We can roll these two APIs back out and document that the components only
>>> provides low-level APIs, forget convenience APIs.
>>>
>>> We can also find a better home for these APIs... like where? On the
>> printer
>>> static side?
>>
>> Commons IO
>>
>>> Gary
>>>
>>> Itv

 On Tue, Jun 14, 2016 at 2:17 AM Gary Gregory 
>>> wrote:

> On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter >>
> wrote:
>
>> I don't like how we're evolving CSVFormat. It is becoming a dumping
> ground
>> for anything that may be useful or convenient. The more methods we
>>> add,
> the
>> harder it becomes for users to find the right method for their use
>>> case.
>>
>
> Small is nice, I get that. But how would you do it differently so
>> that I
> can easily use Paths, Files, URI, and URLs...
>
> Gary
>
>
>>
>> Benedikt
>>
>>  schrieb am Di., 14. Juni 2016 um 07:53 Uhr:
>>
>>> Author: ggregory
>>> Date: Tue Jun 14 05:53:32 2016
>>> New Revision: 1748347
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1748347&view=rev
>>> Log:
>>> Add convenience API CSVFormat.print(File, Charset) (JIRA is down
>>> ATM).
>>>
>>> Modified:
>>> commons/proper/csv/trunk/src/changes/changes.xml
>>>
>>>
>>
>
>>>
>> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>>>
>>>
>>
>
>>>
>> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
>>>
>>> Modified: commons/proper/csv/trunk/src/changes/changes.xml
>>> URL:
>>>
>>
>
>>>
>> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/changes/changes.xml?rev=1748347&r1=1748346&r2=1748347&view=diff
>>>
>>>
>>
>
>>>
>> ==
>>> --- commons/proper/csv/trunk/src/changes/changes.xml (original)
>>> +++ commons/proper/csv/trunk/src/changes/changes.xml Tue Jun 14
> 05:53:32
>>> 2016
>>> @@ -40,6 +40,7 @@
>>>
>>>  
>>> due-to="Gary
>>> Gregory">Update platform requirement from Java 6 to 7.
>>> +  >> due-to="Gary
>>> Gregory">Add convenience API CSVFormat.print(File,
>> Charset)
>>>  
>>>  
>>> due-to="Gary
>>> Gregory">Make CSVPrinter.print(Object) GC-free.
>>>
>>> Modified:
>>>
>>
>
>>>
>> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>>> URL:
>>>
>>
>
>>>
>> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?rev=1748347&r1=1748346&r2=1748347&view=diff
>>>
>>>
>>
>
>>>
>> ==
>>> ---
>>>
>>
>
>>>
>> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>>> (original)
>>> +++
>>>
>>
>
>>>
>> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>>> Tue Jun 14 05:53:32 2016
>>> @@ -28,10 +28,14 @@ import static org.apache.commons.csv.Con
>>>  import static org.apache.commons.csv.Constants.SP;
>>>  import static org.apache.commons.csv.Constants.TAB;
>>>
>>> +import java.io.File;
>>> +import java.io.FileOutputStream;
>>>  import java.io.IOException;
>>> +import java.io.OutputStreamWriter;
>>>  import java.io.Reader;
>>>  import java.io.Serializable;
>>>  import java.io.StringWriter;
>>> +import java.nio.charset.Charset;
>>>  import java.sql.ResultSet;
>>>  import java.sql.ResultSetMetaData;
>>>  import java.sql.SQLException;
>>> @@ -864,6 +868,27 @@ public final class CSVFormat implements
>>>  }
>>>
>>>  /**
>>> + * Prints to the specified output.
>>> + *

Re: [ALL] Volunteers for a Math IPMC?

[John D. Ament]

Generally speaking, incubation is to nurture a community to adopting the
Apache Way.  This includes self governance, community growth and licensing
policies.

We generally expect some kind of backing community to bring this to.  We
have seen pretty consistently that starting from an empty community doesn't
work.  It doesn't mean that it's impossible, but very hard to do.

John

On Tue, Jun 14, 2016 at 3:07 PM Jochen Wiedmann 
wrote:

> On Tue, Jun 14, 2016 at 8:54 PM, Ted Dunning 
> wrote:
> > Looking back through the discussion, it is a bit of a problem that one of
> > the major reasons given for the fork is that the team thought that they
> > didn't have a large enough PMC and that incubation wouldn't get them
> enough
> > additional contributors. That made it seem like the project should go
> > forward without meeting Apache requirements (i.e. outside).
> >
> > Is the situation really that different now that a vastly diminished team
> is
> > likely to benefit from incubation enough to form a viable TLP?
> >
> > (I hate that this sounds negative ... it is a real question)
>
> We can't tell you. It is just, that some of us (including me) have the
> feeling/opinion, that going through the Incubator is the path, where
> the chances are best to attract new committers.
>
> 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: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [ALL] Volunteers for a Math IPMC?

[Ted Dunning]

On Tue, Jun 14, 2016 at 2:29 PM, John D. Ament 
wrote:

> We generally expect some kind of backing community to bring this to.  We
> have seen pretty consistently that starting from an empty community doesn't
> work.  It doesn't mean that it's impossible, but very hard to do.
>

Frankly, the exceptions to this observation (such as Drill) pretty much
reinforce the conclusion. Drill managed to build a community, but only
because of a LOT of effort on the part of the founders of the project.

Jenkins build is unstable: commons-fileupload » Apache Commons FileUpload #12

[Apache Jenkins Server]

See 



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

Jenkins build is unstable: commons-fileupload #12

[Apache Jenkins Server]

See 


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

Jenkins build is back to normal : commons-validator #5

[Apache Jenkins Server]

See 


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

Build failed in Jenkins: commons-net #7

[Apache Jenkins Server]

See 

Changes:

[sebb] Unnecessary; done by connect(String,int)

--
[...truncated 170 lines...]
AU
src/main/java/org/apache/commons/net/ftp/parser/FTPFileEntryParserFactory.java
AU
src/main/java/org/apache/commons/net/ftp/parser/VMSVersioningFTPEntryParser.java
AUsrc/main/java/org/apache/commons/net/ftp/parser/MLSxEntryParser.java
AU
src/main/java/org/apache/commons/net/ftp/parser/ParserInitializationException.java
AUsrc/main/java/org/apache/commons/net/ftp/parser/package-info.java
AU
src/main/java/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactory.java
AUsrc/main/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java
AU
src/main/java/org/apache/commons/net/ftp/parser/FTPTimestampParser.java
AU
src/main/java/org/apache/commons/net/ftp/parser/ConfigurableFTPFileEntryParserImpl.java
AU
src/main/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java
AU
src/main/java/org/apache/commons/net/ftp/parser/EnterpriseUnixFTPEntryParser.java
AU
src/main/java/org/apache/commons/net/ftp/parser/CompositeFileEntryParser.java
A src/main/java/org/apache/commons/net/whois
AUsrc/main/java/org/apache/commons/net/whois/package-info.java
AUsrc/main/java/org/apache/commons/net/whois/WhoisClient.java
A src/main/java/org/apache/commons/net/telnet
AU
src/main/java/org/apache/commons/net/telnet/TelnetNotificationHandler.java
AU
src/main/java/org/apache/commons/net/telnet/TerminalTypeOptionHandler.java
AUsrc/main/java/org/apache/commons/net/telnet/EchoOptionHandler.java
AU
src/main/java/org/apache/commons/net/telnet/InvalidTelnetOptionException.java
AUsrc/main/java/org/apache/commons/net/telnet/SimpleOptionHandler.java
AUsrc/main/java/org/apache/commons/net/telnet/TelnetInputListener.java
AUsrc/main/java/org/apache/commons/net/telnet/TelnetOptionHandler.java
AU
src/main/java/org/apache/commons/net/telnet/SuppressGAOptionHandler.java
AUsrc/main/java/org/apache/commons/net/telnet/TelnetOption.java
AUsrc/main/java/org/apache/commons/net/telnet/package-info.java
AUsrc/main/java/org/apache/commons/net/telnet/TelnetInputStream.java
AUsrc/main/java/org/apache/commons/net/telnet/TelnetOutputStream.java
AU
src/main/java/org/apache/commons/net/telnet/WindowSizeOptionHandler.java
AUsrc/main/java/org/apache/commons/net/telnet/TelnetClient.java
AUsrc/main/java/org/apache/commons/net/telnet/TelnetCommand.java
AUsrc/main/java/org/apache/commons/net/telnet/Telnet.java
A src/main/java/org/apache/commons/net/daytime
AUsrc/main/java/org/apache/commons/net/daytime/DaytimeTCPClient.java
AUsrc/main/java/org/apache/commons/net/daytime/DaytimeUDPClient.java
AUsrc/main/java/org/apache/commons/net/daytime/package-info.java
A src/main/java/org/apache/commons/net/time
AUsrc/main/java/org/apache/commons/net/time/TimeTCPClient.java
AUsrc/main/java/org/apache/commons/net/time/package-info.java
AUsrc/main/java/org/apache/commons/net/time/TimeUDPClient.java
A src/main/java/org/apache/commons/net/ntp
AUsrc/main/java/org/apache/commons/net/ntp/NTPUDPClient.java
AUsrc/main/java/org/apache/commons/net/ntp/TimeInfo.java
AUsrc/main/java/org/apache/commons/net/ntp/NtpV3Impl.java
AUsrc/main/java/org/apache/commons/net/ntp/NtpUtils.java
AUsrc/main/java/org/apache/commons/net/ntp/NtpV3Packet.java
AUsrc/main/java/org/apache/commons/net/ntp/TimeStamp.java
AUsrc/main/java/org/apache/commons/net/ntp/package-info.java
AUsrc/main/java/org/apache/commons/net/DatagramSocketFactory.java
AUsrc/main/java/org/apache/commons/net/package-info.java
AUsrc/main/java/org/apache/commons/net/DefaultSocketFactory.java
AUsrc/main/java/org/apache/commons/net/DefaultDatagramSocketFactory.java
A src/main/java/org/apache/commons/net/io
AUsrc/main/java/org/apache/commons/net/io/SocketInputStream.java
AUsrc/main/java/org/apache/commons/net/io/package-info.java
AUsrc/main/java/org/apache/commons/net/io/CopyStreamException.java
AU
src/main/java/org/apache/commons/net/io/DotTerminatedMessageWriter.java
AUsrc/main/java/org/apache/commons/net/io/SocketOutputStream.java
AUsrc/main/java/org/apache/commons/net/io/CopyStreamAdapter.java
AUsrc/main/java/org/apache/commons/net/io/CopyStreamEvent.java
AU
src/main/java/org/apache/commons/net/io/DotTerminatedMessageReader.java
AUsrc/main/java/org/apache/commons/net/io/CopyStreamListener.java
AUsrc/main/java/org/apache/commons/net/io/Util.java
AUsrc/main/java/org/apache/commons/net/io/ToNetASCIIInputStream.java
AUsrc/main/java/org/apache/

Re: [compress] change behavior of bzip-output finalize?

[Stefan Bodewig]

On 2016-06-13, Stefan Bodewig wrote:

> The bzip2 output stream has a finish method that is used to ensure all
> data has been written to the stream and a separate close method that
> invokes finish. And it overrides finalize to invoke finish in case
> people have forgotten to close the stream - this behavior has been
> present in the very first release of [compress].

It now no longer does. I've updated the changes report to mark the
backwards incompatible change.

Thanks for your advice

   Stefan

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

Re: [lang] replace clirr with japicmp

[Charles Honton]

According to clirr-maven-plugin pom, it depends on 
net.sf.clirr:chirr-core:0.6 (released on 11-Feb-2006)
org.apache.bcel:bel:5.2 (release on 13-Jun-2006)
net.sf.clirr:chirr-core:0.6 had an excluded dependency on bcel:bel:5.1 
(released 22-Nov-2005 and modified 20-Oct-2010)


Yes, japicmp has single developer and nine contributors.  However, that single 
developer has done a great job keeping up to date.  Japicmp is Apache licensed 
.  (Clirr does not 
mention any license in pom) Should Martin Mois decide to quite maintenance, the 
code is available both at GitHub  and Maven 
Central 
. 
(Clirr source jar is not at Maven Central)

Why do we find it so hard to take components or tools off the shelf?  Why are 
we jumping to invest time re-writing when our efforts could better be spent on 
our focus products?

regards,
chas


> On Jun 13, 2016, at 11:20 PM, Gary Gregory  wrote:
> 
> On Mon, Jun 13, 2016 at 11:18 PM, Benedikt Ritter 
> wrote:
> 
>> Jochen Wiedmann  schrieb am Di., 14. Juni 2016
>> um 08:14 Uhr:
>> 
>>> On Tue, Jun 14, 2016 at 8:11 AM, Benedikt Ritter 
>>> wrote:
>>> 
 Charles Honton  schrieb am Di., 14. Juni 2016 um
>> 07:29
>>> Uhr:
 
> Now that lang is compiled with java6, clirr is broken.  Do we want to
> update to a more modern report like japicmp <
> https://siom79.github.io/japicmp/>?
> 
 
 The site build is only broken when build with Java 8. It should be
>>> working
 with Java 6 and Java 7.
>>> 
>>> Lets give the new kid on the block a try. (But don't forget, to
>>> report, what the experiences are.)
>>> 
>> 
>> okay
>> 
>> 
>>> 
>>> Clirr is basically unmaintained, since years. A replacement would
>>> definitely be valuable.
>>> 
>> 
>> Could happen to japicmp sooner or later, since it seems to be maintained by
>> a single person at the moment. I don't like pulling in dependencies like
>> this. But you're right if Clirr is unmaintained.
>> 
> 
> The Clirr Maven plugin is maintained though and there has been talk of it's
> dependency on BCEL being updated.
> 
> I've not looked under the plugin's hood but if the plugin is fiddling with
> BCEL then perhaps it is doing in more than just wrapping Clirr?
> 
> Gary
> 
> 
>> Benedikt
>> 
>> 
>>> Jochen
>>> 
>>> -
>>> 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: [lang] replace clirr with japicmp

[Benedikt Ritter]

Hello Charles,

as I said in response to Jochen, I'm fine with giving japicmp a try. But
for tools as important to us as clirr, I've come to the conclusion that it
would be better to have them at the ASF.

Benedikt

Charles Honton  schrieb am Mi., 15. Juni 2016 um 06:45:

> According to clirr-maven-plugin pom, it depends on
> net.sf.clirr:chirr-core:0.6 (released on 11-Feb-2006)
> org.apache.bcel:bel:5.2 (release on 13-Jun-2006)
> net.sf.clirr:chirr-core:0.6 had an excluded dependency on bcel:bel:5.1
> (released 22-Nov-2005 and modified 20-Oct-2010)
>
>
> Yes, japicmp has single developer and nine contributors.  However, that
> single developer has done a great job keeping up to date.  Japicmp is
> Apache licensed .
> (Clirr does not mention any license in pom) Should Martin Mois decide to
> quite maintenance, the code is available both at GitHub <
> https://github.com/siom79/japicmp> and Maven Central <
> http://repo1.maven.org/maven2/com/github/siom79/japicmp/japicmp/0.8.0/>.
> (Clirr source jar is not at Maven Central)
>
> Why do we find it so hard to take components or tools off the shelf?  Why
> are we jumping to invest time re-writing when our efforts could better be
> spent on our focus products?
>
> regards,
> chas
>
>
> > On Jun 13, 2016, at 11:20 PM, Gary Gregory 
> wrote:
> >
> > On Mon, Jun 13, 2016 at 11:18 PM, Benedikt Ritter 
> > wrote:
> >
> >> Jochen Wiedmann  schrieb am Di., 14. Juni
> 2016
> >> um 08:14 Uhr:
> >>
> >>> On Tue, Jun 14, 2016 at 8:11 AM, Benedikt Ritter 
> >>> wrote:
> >>>
>  Charles Honton  schrieb am Di., 14. Juni 2016 um
> >> 07:29
> >>> Uhr:
> 
> > Now that lang is compiled with java6, clirr is broken.  Do we want to
> > update to a more modern report like japicmp <
> > https://siom79.github.io/japicmp/>?
> >
> 
>  The site build is only broken when build with Java 8. It should be
> >>> working
>  with Java 6 and Java 7.
> >>>
> >>> Lets give the new kid on the block a try. (But don't forget, to
> >>> report, what the experiences are.)
> >>>
> >>
> >> okay
> >>
> >>
> >>>
> >>> Clirr is basically unmaintained, since years. A replacement would
> >>> definitely be valuable.
> >>>
> >>
> >> Could happen to japicmp sooner or later, since it seems to be
> maintained by
> >> a single person at the moment. I don't like pulling in dependencies like
> >> this. But you're right if Clirr is unmaintained.
> >>
> >
> > The Clirr Maven plugin is maintained though and there has been talk of
> it's
> > dependency on BCEL being updated.
> >
> > I've not looked under the plugin's hood but if the plugin is fiddling
> with
> > BCEL then perhaps it is doing in more than just wrapping Clirr?
> >
> > Gary
> >
> >
> >> Benedikt
> >>
> >>
> >>> Jochen
> >>>
> >>> -
> >>> 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: Build failed in Jenkins: commons-net #7

[Benedikt Ritter]

Looks like a new Jenkins related problem. The ClassNotFoundException we saw
in the build jobs of FileUpload and Validator seem to have go away.

Apache Jenkins Server  schrieb am Mi., 15. Juni
2016 um 02:23:

> See 
>
> Changes:
>
> [sebb] Unnecessary; done by connect(String,int)
>
> --
> [...truncated 170 lines...]
> AU
> src/main/java/org/apache/commons/net/ftp/parser/FTPFileEntryParserFactory.java
> AU
> src/main/java/org/apache/commons/net/ftp/parser/VMSVersioningFTPEntryParser.java
> AU
> src/main/java/org/apache/commons/net/ftp/parser/MLSxEntryParser.java
> AU
> src/main/java/org/apache/commons/net/ftp/parser/ParserInitializationException.java
> AUsrc/main/java/org/apache/commons/net/ftp/parser/package-info.java
> AU
> src/main/java/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactory.java
> AU
> src/main/java/org/apache/commons/net/ftp/parser/NTFTPEntryParser.java
> AU
> src/main/java/org/apache/commons/net/ftp/parser/FTPTimestampParser.java
> AU
> src/main/java/org/apache/commons/net/ftp/parser/ConfigurableFTPFileEntryParserImpl.java
> AU
> src/main/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java
> AU
> src/main/java/org/apache/commons/net/ftp/parser/EnterpriseUnixFTPEntryParser.java
> AU
> src/main/java/org/apache/commons/net/ftp/parser/CompositeFileEntryParser.java
> A src/main/java/org/apache/commons/net/whois
> AUsrc/main/java/org/apache/commons/net/whois/package-info.java
> AUsrc/main/java/org/apache/commons/net/whois/WhoisClient.java
> A src/main/java/org/apache/commons/net/telnet
> AU
> src/main/java/org/apache/commons/net/telnet/TelnetNotificationHandler.java
> AU
> src/main/java/org/apache/commons/net/telnet/TerminalTypeOptionHandler.java
> AU
> src/main/java/org/apache/commons/net/telnet/EchoOptionHandler.java
> AU
> src/main/java/org/apache/commons/net/telnet/InvalidTelnetOptionException.java
> AU
> src/main/java/org/apache/commons/net/telnet/SimpleOptionHandler.java
> AU
> src/main/java/org/apache/commons/net/telnet/TelnetInputListener.java
> AU
> src/main/java/org/apache/commons/net/telnet/TelnetOptionHandler.java
> AU
> src/main/java/org/apache/commons/net/telnet/SuppressGAOptionHandler.java
> AUsrc/main/java/org/apache/commons/net/telnet/TelnetOption.java
> AUsrc/main/java/org/apache/commons/net/telnet/package-info.java
> AU
> src/main/java/org/apache/commons/net/telnet/TelnetInputStream.java
> AU
> src/main/java/org/apache/commons/net/telnet/TelnetOutputStream.java
> AU
> src/main/java/org/apache/commons/net/telnet/WindowSizeOptionHandler.java
> AUsrc/main/java/org/apache/commons/net/telnet/TelnetClient.java
> AUsrc/main/java/org/apache/commons/net/telnet/TelnetCommand.java
> AUsrc/main/java/org/apache/commons/net/telnet/Telnet.java
> A src/main/java/org/apache/commons/net/daytime
> AU
> src/main/java/org/apache/commons/net/daytime/DaytimeTCPClient.java
> AU
> src/main/java/org/apache/commons/net/daytime/DaytimeUDPClient.java
> AUsrc/main/java/org/apache/commons/net/daytime/package-info.java
> A src/main/java/org/apache/commons/net/time
> AUsrc/main/java/org/apache/commons/net/time/TimeTCPClient.java
> AUsrc/main/java/org/apache/commons/net/time/package-info.java
> AUsrc/main/java/org/apache/commons/net/time/TimeUDPClient.java
> A src/main/java/org/apache/commons/net/ntp
> AUsrc/main/java/org/apache/commons/net/ntp/NTPUDPClient.java
> AUsrc/main/java/org/apache/commons/net/ntp/TimeInfo.java
> AUsrc/main/java/org/apache/commons/net/ntp/NtpV3Impl.java
> AUsrc/main/java/org/apache/commons/net/ntp/NtpUtils.java
> AUsrc/main/java/org/apache/commons/net/ntp/NtpV3Packet.java
> AUsrc/main/java/org/apache/commons/net/ntp/TimeStamp.java
> AUsrc/main/java/org/apache/commons/net/ntp/package-info.java
> AUsrc/main/java/org/apache/commons/net/DatagramSocketFactory.java
> AUsrc/main/java/org/apache/commons/net/package-info.java
> AUsrc/main/java/org/apache/commons/net/DefaultSocketFactory.java
> AU
> src/main/java/org/apache/commons/net/DefaultDatagramSocketFactory.java
> A src/main/java/org/apache/commons/net/io
> AUsrc/main/java/org/apache/commons/net/io/SocketInputStream.java
> AUsrc/main/java/org/apache/commons/net/io/package-info.java
> AUsrc/main/java/org/apache/commons/net/io/CopyStreamException.java
> AU
> src/main/java/org/apache/commons/net/io/DotTerminatedMessageWriter.java
> AUsrc/main/java/org/apache/commons/net/io/SocketOutputStream.java
> AUsrc/main/java/org/apache/commons/net/io/CopyStreamAdapter.java
> AUsrc/main/java/org/apache/commons/net/io/CopyStreamEvent.java
> AU
> src/main/java/org/apache/commons/net/io/DotTerminatedMessageReader.java
> AUsrc/main/java/org/apache/commons/net/io/C

Re: [ALL] Volunteers for a Math IPMC?

[Jochen Wiedmann]

On Tue, Jun 14, 2016 at 11:29 PM, John D. Ament  wrote:

> We generally expect some kind of backing community to bring this to.  We
> have seen pretty consistently that starting from an empty community doesn't
> work.  It doesn't mean that it's impossible, but very hard to do.

Understood. On the other hand: Would that be sufficient reason for
rejecting a proposal? ("It didn't
work in the past" != "It won't work in this case")


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

Re: [lang] replace clirr with japicmp

[Jochen Wiedmann]

On Wed, Jun 15, 2016 at 6:45 AM, Charles Honton  wrote:
> According to clirr-maven-plugin pom, it depends on
> net.sf.clirr:chirr-core:0.6 (released on 11-Feb-2006)
> org.apache.bcel:bel:5.2 (release on 13-Jun-2006)
> net.sf.clirr:chirr-core:0.6 had an excluded dependency on bcel:bel:5.1 
> (released 22-Nov-2005 and modified 20-Oct-2010)
>
>
> Yes, japicmp has single developer and nine contributors.  However, that 
> single developer has done a great job keeping up to date.  Japicmp is Apache 
> licensed .  (Clirr 
> does not mention any license in pom) Should Martin Mois decide to quite 
> maintenance, the code is available both at GitHub 
>  and Maven Central 
> . 
> (Clirr source jar is not at Maven Central)
>
> Why do we find it so hard to take components or tools off the shelf?  Why are 
> we jumping to invest time re-writing when our efforts could better be spent 
> on our focus products?

If I remember correctly, nobody rejected giving japicmp a try.

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

Re: Jenkins build is unstable: commons-fileupload » Apache Commons FileUpload #12

[Jochen Wiedmann]

The last failure was due to errors in the test suite. Should be fixed.

Sorry,

Jochen


On Wed, Jun 15, 2016 at 1:51 AM, Apache Jenkins Server
 wrote:
> See 
> 
>



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