Re: [codec] ready for a release

[Stian Soiland-Reyes]

A bit better now; I removed the 3 (!)  BOMs in changes.xml,
upgraded the commons parent version and findbugs version.


Ubuntu 16.04

mvn clean install site with OpenJDK 8 works.

mvn clean install with OpenJDK 9 works.


Ubuntu 14.04

 mvn clean install with Java 6 works.


But I can't do "mvn site" with Java 6 due to newer checkstyle (from
Commons Parent)

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on
project commons-codec: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.4:site failed: An API
incompatibility was encountered while executing
org.apache.maven.plugins:maven-site-plugin:3.4:site:
java.lang.UnsupportedClassVersionError:
org/apache/maven/plugin/checkstyle/CheckstyleReport : Unsupported
major.minor version 51.0

which I think is OK - we already discussed this when releasing parent 41.

On 17 September 2016 at 11:23, Emmanuel Bourg  wrote:
> Le 16/09/2016 à 00:49, Gary Gregory a écrit :
>> I'd like to start a release for [codec]. If you want to review the code
>> now, please do so.
>
> I tried to build the site but the BOM in changes.xml crashed the changes
> plugin, and clirr is unable to run for some reason. The changes look good.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: AW: Java8 utilities

[Gary Gregory]

I do not think we should talk about future plans in the release notes for
3.5.

Gary

On Sep 21, 2016 2:58 PM, "Stian Soiland-Reyes"  wrote:

> +1 - could we even mention this in the release notes for 3.5 and 3.6?
>
> Something like:
>
> > Commons Lang 3.5.x is planned to be the last minor version series that
> > support Java 6; future versions will target Java 7 and Java 8.
>
>
> > Commons Lang 3.6.x is planned to be the last minor version series that
> > support Java 7; future versions will target Java 8.
>
> Then downstream users have a chance to complain to us if they don't
> like it :-)  (and hopefully put in the effort required)
>
> On 21 September 2016 at 19:20, Gary Gregory 
> wrote:
> > I'd like to propose an orderly migration assume BC is preserved:
> >
> > - Release 3.5 RC as scheduled this weekend
> > - Release 3.6 with Java 7 changes
> > - Release 3.7 with Java 8 changes
> >
> > This will give us an opportunity to do some Java 7 work and put that out
> > without leaving Java 7-only folks out of the picture.
> >
> > Gary
> >
> >
> > On Wed, Sep 21, 2016 at 10:21 AM, Stian Soiland-Reyes 
> > wrote:
> >
> >> +1 to be brave and make Lang 3.6 be Java 8, so Lambda helpers can join
> >> here. I have a couple of Stream helpers that could also fit in there.
> >>
> >>
> >>
> >> On 21 September 2016 at 18:19, Gary Gregory 
> >> wrote:
> >> > On Wed, Sep 21, 2016 at 8:04 AM, Benedikt Ritter 
> >> wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> Jörg Schaible  schrieb am Mi., 21.
> Sep.
> >> >> 2016 um 16:55 Uhr:
> >> >>
> >> >> > Jan Matèrne (jhm) wrote:
> >> >> >
> >> >> > >
> >> >> > >> We could also have Lamda utility classes in [lang], the classes
> >> would
> >> >> > >> target Java 8 while the other classes would remain at the Java 6
> >> level
> >> >> > >> (this implies compiling the classes separately and recombining
> >> them in
> >> >> > >> the final jar).
> >> >> > >
> >> >> > > From a users point of view I would search in commons-lang for
> >> language
> >> >> > > "extensions". But this kind of building would be ... complex.
> >> >> >
> >> >> > No, it's a quite simple configuration with Maven. However, you have
> >> to be
> >> >> > prepared for users running into problems using the resulting jar
> file:
> >> >> >
> >> >> > 1/ in Android, because the Dalvik compiler is not able to convert
> the
> >> >> > classes targeting Java 8
> >> >> >
> >> >> > 2/ in Web/App Servers running with Java 7 or below that scan the
> >> >> libraries
> >> >> > in the classpath for annotations
> >> >> >
> >> >>
> >> >> I still think we should use Commons Functor for this kind of
> >> functionality.
> >> >> Commons Lang originally only hosted extensions to the java.lang
> package.
> >> >> Over time more and more stuff creeped in (reflect, concurrent,
> text). We
> >> >> responded to that by creating Commons Text and Commons Functor. I
> think
> >> >> small focused components are the right direction instead of putting
> even
> >> >> more stuff into Commons Lang. I hope to have some time to work on
> Text
> >> and
> >> >> Functor after I'm done with the Commons Lang 3.5 release... :)
> >> >>
> >> >
> >> > Once [lang] 3.5 is out, I think we should update [lang] to Java 7. We
> >> could
> >> > talk about going directly to Java 8.
> >> >
> >> > Lambdas are a core Java feature, it feel to me like it belongs in
> [lang].
> >> > [functor] feels like something that should only be for pre-Java 8.
> >> >
> >> > Gary
> >> >
> >> >>
> >> >> Regards,
> >> >> Benedikt
> >> >>
> >> >>
> >> >> >
> >> >> > Cheers,
> >> >> > Jörg
> >> >> >
> >> >> >
> >> >> > 
> -
> >> >> > 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
> >>
> >>
> >>
> >> --
> >> Stian Soiland-Reyes
> >> http://orcid.org/-0001-9842-9718
> >>
> >> -
> >> 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 

Re: AW: Java8 utilities

[Stian Soiland-Reyes]

+1 - could we even mention this in the release notes for 3.5 and 3.6?

Something like:

> Commons Lang 3.5.x is planned to be the last minor version series that
> support Java 6; future versions will target Java 7 and Java 8.


> Commons Lang 3.6.x is planned to be the last minor version series that
> support Java 7; future versions will target Java 8.

Then downstream users have a chance to complain to us if they don't
like it :-)  (and hopefully put in the effort required)

On 21 September 2016 at 19:20, Gary Gregory  wrote:
> I'd like to propose an orderly migration assume BC is preserved:
>
> - Release 3.5 RC as scheduled this weekend
> - Release 3.6 with Java 7 changes
> - Release 3.7 with Java 8 changes
>
> This will give us an opportunity to do some Java 7 work and put that out
> without leaving Java 7-only folks out of the picture.
>
> Gary
>
>
> On Wed, Sep 21, 2016 at 10:21 AM, Stian Soiland-Reyes 
> wrote:
>
>> +1 to be brave and make Lang 3.6 be Java 8, so Lambda helpers can join
>> here. I have a couple of Stream helpers that could also fit in there.
>>
>>
>>
>> On 21 September 2016 at 18:19, Gary Gregory 
>> wrote:
>> > On Wed, Sep 21, 2016 at 8:04 AM, Benedikt Ritter 
>> wrote:
>> >
>> >> Hi,
>> >>
>> >> Jörg Schaible  schrieb am Mi., 21. Sep.
>> >> 2016 um 16:55 Uhr:
>> >>
>> >> > Jan Matèrne (jhm) wrote:
>> >> >
>> >> > >
>> >> > >> We could also have Lamda utility classes in [lang], the classes
>> would
>> >> > >> target Java 8 while the other classes would remain at the Java 6
>> level
>> >> > >> (this implies compiling the classes separately and recombining
>> them in
>> >> > >> the final jar).
>> >> > >
>> >> > > From a users point of view I would search in commons-lang for
>> language
>> >> > > "extensions". But this kind of building would be ... complex.
>> >> >
>> >> > No, it's a quite simple configuration with Maven. However, you have
>> to be
>> >> > prepared for users running into problems using the resulting jar file:
>> >> >
>> >> > 1/ in Android, because the Dalvik compiler is not able to convert the
>> >> > classes targeting Java 8
>> >> >
>> >> > 2/ in Web/App Servers running with Java 7 or below that scan the
>> >> libraries
>> >> > in the classpath for annotations
>> >> >
>> >>
>> >> I still think we should use Commons Functor for this kind of
>> functionality.
>> >> Commons Lang originally only hosted extensions to the java.lang package.
>> >> Over time more and more stuff creeped in (reflect, concurrent, text). We
>> >> responded to that by creating Commons Text and Commons Functor. I think
>> >> small focused components are the right direction instead of putting even
>> >> more stuff into Commons Lang. I hope to have some time to work on Text
>> and
>> >> Functor after I'm done with the Commons Lang 3.5 release... :)
>> >>
>> >
>> > Once [lang] 3.5 is out, I think we should update [lang] to Java 7. We
>> could
>> > talk about going directly to Java 8.
>> >
>> > Lambdas are a core Java feature, it feel to me like it belongs in [lang].
>> > [functor] feels like something that should only be for pre-Java 8.
>> >
>> > Gary
>> >
>> >>
>> >> Regards,
>> >> Benedikt
>> >>
>> >>
>> >> >
>> >> > Cheers,
>> >> > Jörg
>> >> >
>> >> >
>> >> > -
>> >> > 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
>>
>>
>>
>> --
>> Stian Soiland-Reyes
>> http://orcid.org/-0001-9842-9718
>>
>> -
>> 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



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: AW: Java8 utilities

[Gary Gregory]

I'd like to propose an orderly migration assume BC is preserved:

- Release 3.5 RC as scheduled this weekend
- Release 3.6 with Java 7 changes
- Release 3.7 with Java 8 changes

This will give us an opportunity to do some Java 7 work and put that out
without leaving Java 7-only folks out of the picture.

Gary


On Wed, Sep 21, 2016 at 10:21 AM, Stian Soiland-Reyes 
wrote:

> +1 to be brave and make Lang 3.6 be Java 8, so Lambda helpers can join
> here. I have a couple of Stream helpers that could also fit in there.
>
>
>
> On 21 September 2016 at 18:19, Gary Gregory 
> wrote:
> > On Wed, Sep 21, 2016 at 8:04 AM, Benedikt Ritter 
> wrote:
> >
> >> Hi,
> >>
> >> Jörg Schaible  schrieb am Mi., 21. Sep.
> >> 2016 um 16:55 Uhr:
> >>
> >> > Jan Matèrne (jhm) wrote:
> >> >
> >> > >
> >> > >> We could also have Lamda utility classes in [lang], the classes
> would
> >> > >> target Java 8 while the other classes would remain at the Java 6
> level
> >> > >> (this implies compiling the classes separately and recombining
> them in
> >> > >> the final jar).
> >> > >
> >> > > From a users point of view I would search in commons-lang for
> language
> >> > > "extensions". But this kind of building would be ... complex.
> >> >
> >> > No, it's a quite simple configuration with Maven. However, you have
> to be
> >> > prepared for users running into problems using the resulting jar file:
> >> >
> >> > 1/ in Android, because the Dalvik compiler is not able to convert the
> >> > classes targeting Java 8
> >> >
> >> > 2/ in Web/App Servers running with Java 7 or below that scan the
> >> libraries
> >> > in the classpath for annotations
> >> >
> >>
> >> I still think we should use Commons Functor for this kind of
> functionality.
> >> Commons Lang originally only hosted extensions to the java.lang package.
> >> Over time more and more stuff creeped in (reflect, concurrent, text). We
> >> responded to that by creating Commons Text and Commons Functor. I think
> >> small focused components are the right direction instead of putting even
> >> more stuff into Commons Lang. I hope to have some time to work on Text
> and
> >> Functor after I'm done with the Commons Lang 3.5 release... :)
> >>
> >
> > Once [lang] 3.5 is out, I think we should update [lang] to Java 7. We
> could
> > talk about going directly to Java 8.
> >
> > Lambdas are a core Java feature, it feel to me like it belongs in [lang].
> > [functor] feels like something that should only be for pre-Java 8.
> >
> > Gary
> >
> >>
> >> Regards,
> >> Benedikt
> >>
> >>
> >> >
> >> > Cheers,
> >> > Jörg
> >> >
> >> >
> >> > -
> >> > 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
>
>
>
> --
> Stian Soiland-Reyes
> http://orcid.org/-0001-9842-9718
>
> -
> 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: [ALL] Valid reasons for blocking a release?

[Stian Soiland-Reyes]

I don't think a valid site or the odd missing file is enough to cancel
a release - but if there are multiple such issues it should also be
taken into consideration.

Even the odd -1 vote can be ignored if there are enough positive votes.

On 15 September 2016 at 12:42, Stefan Bodewig  wrote:
> On 2016-09-15, Gilles wrote:
>
>> On Wed, 14 Sep 2016 07:41:01 -0700, Gary Gregory wrote:
>>> "I'd rather not redo the release steps just for files that are
>>> meaningful only when browsing the code repository mirror at
>>> Github."
>
>>> I know our release process is a pain, so maybe we should see if we
>>> can
>>> improve it. This needs a separate thread.
>
>> I'm not the one who complains regularly that the release process
>> is a "nightmare".
>
> I don't share this sentiment. There are a quite a few manual steps, but
> I don't believe they can be avoided.
>
> Then again I've cut enough releases to know which alternative has worked
> for me.
>
> My workflow is different enough that it likely never is the first option
> you find in the docs. At least when uploading stuff to Nexus it is not
> even listed as alternative at all (I use an upload bundle). I didn't
> want to pollute the instructions with even more alternatives.
>
>> Who decided that "README.md" and "CONTRIBUTING.md" _had_ to be part
>> of the distribution files?
>
> I don't think anybody decided that. What I'd expect (I didn't
> participate in the RNG vote, sorry) is that the source distribution
> matches the git tag. And I think this was what Stian brought up. It's
> not about the two files but about the difference between tag and
> distribution.
>
> We've probably never formally said the two should match either, it's
> just what I'd expect. Why would anybody want to exclude anything from
> the source distribution that is inside or SCM?
>
>>> It's rare to release without more than one RC.
>
>> You'd have to wonder why.
>
> One thing RMs tend to forget is that there is no veto on a release
> vote. If you've got enough +1s you can simply go ahead if you disagree
> with the occasional -1.
>
>>> It looks pretty lame IMO if the first thing you see, our site or
>>> github, is wrong or missing info. It could make one wonder about
>>> overall attention to detail...
>
>> Nothing _looks_ lame.
>
> Please mind Gary's "IMO" in the paragraph above.
>
> "lame" is hardly objective :-)
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: AW: Java8 utilities

[Stian Soiland-Reyes]

+1 to be brave and make Lang 3.6 be Java 8, so Lambda helpers can join
here. I have a couple of Stream helpers that could also fit in there.



On 21 September 2016 at 18:19, Gary Gregory  wrote:
> On Wed, Sep 21, 2016 at 8:04 AM, Benedikt Ritter  wrote:
>
>> Hi,
>>
>> Jörg Schaible  schrieb am Mi., 21. Sep.
>> 2016 um 16:55 Uhr:
>>
>> > Jan Matèrne (jhm) wrote:
>> >
>> > >
>> > >> We could also have Lamda utility classes in [lang], the classes would
>> > >> target Java 8 while the other classes would remain at the Java 6 level
>> > >> (this implies compiling the classes separately and recombining them in
>> > >> the final jar).
>> > >
>> > > From a users point of view I would search in commons-lang for language
>> > > "extensions". But this kind of building would be ... complex.
>> >
>> > No, it's a quite simple configuration with Maven. However, you have to be
>> > prepared for users running into problems using the resulting jar file:
>> >
>> > 1/ in Android, because the Dalvik compiler is not able to convert the
>> > classes targeting Java 8
>> >
>> > 2/ in Web/App Servers running with Java 7 or below that scan the
>> libraries
>> > in the classpath for annotations
>> >
>>
>> I still think we should use Commons Functor for this kind of functionality.
>> Commons Lang originally only hosted extensions to the java.lang package.
>> Over time more and more stuff creeped in (reflect, concurrent, text). We
>> responded to that by creating Commons Text and Commons Functor. I think
>> small focused components are the right direction instead of putting even
>> more stuff into Commons Lang. I hope to have some time to work on Text and
>> Functor after I'm done with the Commons Lang 3.5 release... :)
>>
>
> Once [lang] 3.5 is out, I think we should update [lang] to Java 7. We could
> talk about going directly to Java 8.
>
> Lambdas are a core Java feature, it feel to me like it belongs in [lang].
> [functor] feels like something that should only be for pre-Java 8.
>
> Gary
>
>>
>> Regards,
>> Benedikt
>>
>>
>> >
>> > Cheers,
>> > Jörg
>> >
>> >
>> > -
>> > 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



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: AW: Java8 utilities

[Gary Gregory]

On Wed, Sep 21, 2016 at 8:04 AM, Benedikt Ritter  wrote:

> Hi,
>
> Jörg Schaible  schrieb am Mi., 21. Sep.
> 2016 um 16:55 Uhr:
>
> > Jan Matèrne (jhm) wrote:
> >
> > >
> > >> We could also have Lamda utility classes in [lang], the classes would
> > >> target Java 8 while the other classes would remain at the Java 6 level
> > >> (this implies compiling the classes separately and recombining them in
> > >> the final jar).
> > >
> > > From a users point of view I would search in commons-lang for language
> > > "extensions". But this kind of building would be ... complex.
> >
> > No, it's a quite simple configuration with Maven. However, you have to be
> > prepared for users running into problems using the resulting jar file:
> >
> > 1/ in Android, because the Dalvik compiler is not able to convert the
> > classes targeting Java 8
> >
> > 2/ in Web/App Servers running with Java 7 or below that scan the
> libraries
> > in the classpath for annotations
> >
>
> I still think we should use Commons Functor for this kind of functionality.
> Commons Lang originally only hosted extensions to the java.lang package.
> Over time more and more stuff creeped in (reflect, concurrent, text). We
> responded to that by creating Commons Text and Commons Functor. I think
> small focused components are the right direction instead of putting even
> more stuff into Commons Lang. I hope to have some time to work on Text and
> Functor after I'm done with the Commons Lang 3.5 release... :)
>

Once [lang] 3.5 is out, I think we should update [lang] to Java 7. We could
talk about going directly to Java 8.

Lambdas are a core Java feature, it feel to me like it belongs in [lang].
[functor] feels like something that should only be for pre-Java 8.

Gary

>
> Regards,
> Benedikt
>
>
> >
> > Cheers,
> > Jörg
> >
> >
> > -
> > 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: commons-io git commit: Remove redundant type arguments.

[Gary Gregory]

My git config --global core.autocrlf is already true... could the file in
Git have been stored with Windows EOLs?

Gary



On Wed, Sep 21, 2016 at 2:05 AM, Benedikt Ritter  wrote:

> Hi Gary,
>
> is you line ending set up correct? See
> https://help.github.com/articles/dealing-with-line-endings/
>
> Can you please revert the commit and then commit only the stuff you wanted
> to change?
>
> Thank you!
> Benedikt
>
> Gary Gregory  schrieb am Di., 20. Sep. 2016 um
> 17:01 Uhr:
>
> > This annoying :-( it must be an EOL thing.
> >
> > Gary
> >
> > On Sep 20, 2016 7:18 AM, "Matt Sicker"  wrote:
> >
> > > Did the line ending change?
> > >
> > > On 20 September 2016 at 01:59, Benedikt Ritter 
> > wrote:
> > >
> > > > Hello Gary,
> > > >
> > > > why has the whole file changed?
> > > >
> > > > Regards,
> > > > Benedikt
> > > >
> > > >  schrieb am Di., 20. Sep. 2016 um 07:40 Uhr:
> > > >
> > > > > Repository: commons-io
> > > > > Updated Branches:
> > > > >   refs/heads/master 9ba9b49af -> 822bd135f
> > > > >
> > > > >
> > > > > Remove redundant type arguments.
> > > > >
> > > > > Project: http://git-wip-us.apache.org/repos/asf/commons-io/repo
> > > > > Commit: http://git-wip-us.apache.org/repos/asf/commons-io/commit/
> > > > 822bd135
> > > > > Tree:
> > http://git-wip-us.apache.org/repos/asf/commons-io/tree/822bd135
> > > > > Diff:
> > http://git-wip-us.apache.org/repos/asf/commons-io/diff/822bd135
> > > > >
> > > > > Branch: refs/heads/master
> > > > > Commit: 822bd135f3a54b8fbeb23c313535b13c18198c3a
> > > > > Parents: 9ba9b49
> > > > > Author: Gary Gregory 
> > > > > Authored: Mon Sep 19 22:40:29 2016 -0700
> > > > > Committer: Gary Gregory 
> > > > > Committed: Mon Sep 19 22:40:29 2016 -0700
> > > > >
> > > > >
> > --
> > > > >  .../commons/io/input/ObservableInputStream.java | 476
> > > > +--
> > > > >  1 file changed, 238 insertions(+), 238 deletions(-)
> > > > >
> > --
> > > > >
> > > > >
> > > > >
> > > > > http://git-wip-us.apache.org/repos/asf/commons-io/blob/
> > > > 822bd135/src/main/java/org/apache/commons/io/input/
> > > > ObservableInputStream.java
> > > > >
> > --
> > > > > diff --git
> > > > >
> > a/src/main/java/org/apache/commons/io/input/ObservableInputStream.java
> > > > >
> > b/src/main/java/org/apache/commons/io/input/ObservableInputStream.java
> > > > > index 7d13472..c580ba4 100644
> > > > > --- a/src/main/java/org/apache/commons/io/input/
> > > > ObservableInputStream.java
> > > > > +++ b/src/main/java/org/apache/commons/io/input/
> > > > ObservableInputStream.java
> > > > > @@ -1,238 +1,238 @@
> > > > > -/*
> > > > > - * Licensed to the Apache Software Foundation (ASF) under one or
> > more
> > > > > - * contributor license agreements.  See the NOTICE file
> distributed
> > > with
> > > > > - * this work for additional information regarding copyright
> > ownership.
> > > > > - * The ASF licenses this file to You under the Apache License,
> > Version
> > > > 2.0
> > > > > - * (the "License"); you may not use this file except in compliance
> > > with
> > > > > - * the License.  You may obtain a copy of the License at
> > > > > - *
> > > > > - *  http://www.apache.org/licenses/LICENSE-2.0
> > > > > - *
> > > > > - * Unless required by applicable law or agreed to in writing,
> > software
> > > > > - * distributed under the License is distributed on an "AS IS"
> BASIS,
> > > > > - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > > > > implied.
> > > > > - * See the License for the specific language governing permissions
> > and
> > > > > - * limitations under the License.
> > > > > - */
> > > > > -package org.apache.commons.io.input;
> > > > > -
> > > > > -import java.io.IOException;
> > > > > -import java.io.InputStream;
> > > > > -import java.security.MessageDigest;
> > > > > -import java.util.ArrayList;
> > > > > -import java.util.List;
> > > > > -
> > > > > -
> > > > > -/**
> > > > > - * The {@link ObservableInputStream} allows, that an InputStream
> may
> > > be
> > > > > consumed
> > > > > - * by other receivers, apart from the thread, which is reading it.
> > > > > - * The other consumers are implemented as instances of {@link
> > > > Observer}. A
> > > > > - * typical application may be the generation of a {@link
> > > MessageDigest}
> > > > > on the
> > > > > - * fly.
> > > > > - * {@code Note}: The {@link ObservableInputStream} is not
> > > > thread
> > > > > safe,
> > > > > - * as instances of InputStream usually aren't.
> > > > > - * If you must access the stream from multiple threads, then
> > > > > synchronization, locking,
> > > > > - * or a similar means must be used.
> > > > > - * @see 

[VOTE] Release Commons BeanUtils 1.9.3 RC3

[Stian Soiland-Reyes]

This is a [VOTE] for releasing Apache Commons BeanUtils 1.9.3 (from RC3)

This should fix earlier Java 6 / Maven 3.0 build issues with RC2 and
adds a BUILDING.txt

(Tested with Centos 6, Oracle JDK 6 and Maven 3.0.4)


SVN tag (rev 1761786):
 
https://svn.apache.org/repos/asf/commons/proper/beanutils/tags/BEANUTILS_1_9_3_RC3/

Site:
  https://stain.github.io/commons-beanutils/1.9.3-rc3/

Javadoc:
  https://stain.github.io/commons-beanutils/1.9.3-rc3/apidocs/index.html

API changes since 1.9.2 (japicmp):
  
https://stain.github.io/commons-beanutils/1.9.3-rc3/japicmp-maven-plugin-report.html

  (Note: "Semantic Versioning: 0.0.1" indicates the API differences
are compatible with a patch revision)

RAT report:
  https://stain.github.io/commons-beanutils/1.9.3-rc3/rat-report.html


Distribution files (rev 15476)
  https://dist.apache.org/repos/dist/dev/commons/beanutils/BEANUTILS_1_9_3_RC3/


Distribution files hashes (SHA1):

4c285c2c9af35be0ea77e6ada9674e2c7b226fa6  commons-beanutils-1.9.3-bin.tar.gz
b2e6f70aaa2ca500899cb149c919b6bbb0256f96  commons-beanutils-1.9.3-bin.zip
d9f237583ab7b8b4a4bdf55694e915b5af9e165a  commons-beanutils-1.9.3-src.tar.gz
cc16e32ec4acdf8a78c3cae0c7b85cec3a773190  commons-beanutils-1.9.3-src.zip


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

Maven artifacts:
  https://repository.apache.org/content/repositories/orgapachecommons-1202/



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

This vote will be open for at least 72 hours, let's say 2016-09-25T08:00:00Z



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [RNG] Scope of "Commons RNG"

[Emmanuel Bourg]

Le 21/09/2016 à 14:46, Gilles a écrit :

> If we want "Commons RNG" to be a repository of all
> generators that exist out there, irrespective of their
> known weaknesses, it's fine; but we should be careful to
> not let casual users just pick one of the implementations
> on the premise that the library focuses on high quality
> generators.

I think it's fine to have weaker implementations as long as they are
properly documented with the necessary warnings. There aren't that many
algorithms anyway, we'll quickly have the interesting ones.


> I have no issue with adding any new implementation,[4]
> on the conditions that it comes with
>  1. a unit test where the output (say, a few hundred
> numbers) of "Commons RNG" is compared against a
> "reference" implementation,[5]
>  2. the outputs of the "RandomStressTester"[6] piping
> from the "Dieharder" and "TU01/BigCrush" actual
> stress test suites.[7]

Sounds fair


> [1] Emmanuel, if you don't mind, we'd thus set the JIRA
> issue "type" to "wish" rather than "improvement".

As you want, that doesn't make a big difference. It could even qualify
for the "New Feature" type.

> [2] https://xkcd.com/221/

Now I'm tempted to implement a XKCDRandomGenerator just for fun :)

> [3] Up to now, I had assumed that no known-to-be-bad
> generators would be part of "Commons RNG" (except
> "JDK", for reference purposes).

Note that as time goes some generators will be supplanted by better
ones, so Commons RNG will inevitably contain implementations weaker than
the then current state of the art.

> [4] It is not a problem to wait another couple of weeks
> for the additional code, before releasing 1.0.

Ok, I can try implementing LCGs then.

Emmanuel Bourg


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

Re: AW: Java8 utilities

[Gilles]

On Wed, 21 Sep 2016 15:04:12 +, Benedikt Ritter wrote:

Hi,

Jörg Schaible  schrieb am Mi., 21. 
Sep.

2016 um 16:55 Uhr:


Jan Matèrne (jhm) wrote:

>
>> We could also have Lamda utility classes in [lang], the classes 
would
>> target Java 8 while the other classes would remain at the Java 6 
level
>> (this implies compiling the classes separately and recombining 
them in

>> the final jar).
>
> From a users point of view I would search in commons-lang for 
language

> "extensions". But this kind of building would be ... complex.

No, it's a quite simple configuration with Maven. However, you have 
to be
prepared for users running into problems using the resulting jar 
file:


1/ in Android, because the Dalvik compiler is not able to convert 
the

classes targeting Java 8

2/ in Web/App Servers running with Java 7 or below that scan the 
libraries

in the classpath for annotations



I still think we should use Commons Functor for this kind of 
functionality.
Commons Lang originally only hosted extensions to the java.lang 
package.
Over time more and more stuff creeped in (reflect, concurrent, text). 
We
responded to that by creating Commons Text and Commons Functor. I 
think

small focused components are the right direction


Yes!


instead of putting even
more stuff into Commons Lang. I hope to have some time to work on 
Text and

Functor after I'm done with the Commons Lang 3.5 release... :)


Don't you want to deprecate a few things, that came from extending
"java.util" (just as an example)?  ;-)

Gilles


Regards,
Benedikt




Cheers,
Jörg




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

Re: Java8 utilities

[Emmanuel Bourg]

Le 21/09/2016 à 15:17, Jan Matèrne (jhm) a écrit :
> I thought about creating a PR for supplying helper methods for Java8
> lambdas.

Out of curiosity, what kind of methods do you have in mind?

Emmanuel Bourg


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

Re: AW: Java8 utilities

[Benedikt Ritter]

Hi,

Jörg Schaible  schrieb am Mi., 21. Sep.
2016 um 16:55 Uhr:

> Jan Matèrne (jhm) wrote:
>
> >
> >> We could also have Lamda utility classes in [lang], the classes would
> >> target Java 8 while the other classes would remain at the Java 6 level
> >> (this implies compiling the classes separately and recombining them in
> >> the final jar).
> >
> > From a users point of view I would search in commons-lang for language
> > "extensions". But this kind of building would be ... complex.
>
> No, it's a quite simple configuration with Maven. However, you have to be
> prepared for users running into problems using the resulting jar file:
>
> 1/ in Android, because the Dalvik compiler is not able to convert the
> classes targeting Java 8
>
> 2/ in Web/App Servers running with Java 7 or below that scan the libraries
> in the classpath for annotations
>

I still think we should use Commons Functor for this kind of functionality.
Commons Lang originally only hosted extensions to the java.lang package.
Over time more and more stuff creeped in (reflect, concurrent, text). We
responded to that by creating Commons Text and Commons Functor. I think
small focused components are the right direction instead of putting even
more stuff into Commons Lang. I hope to have some time to work on Text and
Functor after I'm done with the Commons Lang 3.5 release... :)

Regards,
Benedikt


>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: AW: Java8 utilities

[Jörg Schaible]

Jan Matèrne (jhm) wrote:

>  
>> We could also have Lamda utility classes in [lang], the classes would
>> target Java 8 while the other classes would remain at the Java 6 level
>> (this implies compiling the classes separately and recombining them in
>> the final jar).
> 
> From a users point of view I would search in commons-lang for language
> "extensions". But this kind of building would be ... complex.

No, it's a quite simple configuration with Maven. However, you have to be 
prepared for users running into problems using the resulting jar file:

1/ in Android, because the Dalvik compiler is not able to convert the 
classes targeting Java 8

2/ in Web/App Servers running with Java 7 or below that scan the libraries 
in the classpath for annotations

Cheers,
Jörg


-
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-beanutils #10

[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-beanutils » Apache Commons BeanUtils #10

[Apache Jenkins Server]

See 



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

AW: Java8 utilities

[jhm]

 
> We could also have Lamda utility classes in [lang], the classes would
> target Java 8 while the other classes would remain at the Java 6 level
> (this implies compiling the classes separately and recombining them in
> the final jar).

>From a users point of view I would search in commons-lang for language 
>"extensions".
But this kind of building would be ... complex.

Jan


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

Re: Java8 utilities

[Emmanuel Bourg]

Le 21/09/2016 à 15:24, Bruno P. Kinoshita a écrit :

> Thoughts?

We could also have Lamda utility classes in [lang], the classes would
target Java 8 while the other classes would remain at the Java 6 level
(this implies compiling the classes separately and recombining them in
the final jar).

Emmanuel Bourg


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

Re: Java8 utilities

[Benedikt Ritter]

Bruno P. Kinoshita  schrieb am Mi., 21.
Sep. 2016 um 15:27 Uhr:

> I wonder if perhaps [functor] could become a place only for Java8+ FP
> utilities.
>
> It was created before Java8, but it's still not complete. There was some
> work to have a parent project, and the idea was to have a pre-Java8
> implementation, and another Java8+. But since we lost momentum, I think we
> could focus only in adding interesting FP utilities, not provided in the
> language itself.
>
> Thoughts?
>

+1


>
> Bruno
>
>
>
> >
> > From: Jan Matèrne (jhm) 
> >To: 'Commons Developers List' 
> >Sent: Thursday, 22 September 2016 1:17 AM
> >Subject: Java8 utilities
> >
> >
> >I thought about creating a PR for supplying helper methods for Java8
> >lambdas.
> >
> >My intented target was commons-lang, but this is Java6.
> >
> >
> >
> >Where could I propose the helpers?`
> >
> >
> >
> >
> >
> >Jan
> >
> >
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Java8 utilities

[Bruno P. Kinoshita]

I wonder if perhaps [functor] could become a place only for Java8+ FP utilities.

It was created before Java8, but it's still not complete. There was some work 
to have a parent project, and the idea was to have a pre-Java8 implementation, 
and another Java8+. But since we lost momentum, I think we could focus only in 
adding interesting FP utilities, not provided in the language itself.

Thoughts?

Bruno



>
> From: Jan Matèrne (jhm) 
>To: 'Commons Developers List'  
>Sent: Thursday, 22 September 2016 1:17 AM
>Subject: Java8 utilities
> 
>
>I thought about creating a PR for supplying helper methods for Java8
>lambdas.
>
>My intented target was commons-lang, but this is Java6.
>
>
>
>Where could I propose the helpers?`
>
>
>
>
>
>Jan
>
>
>
>

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

Java8 utilities

[jhm]

I thought about creating a PR for supplying helper methods for Java8
lambdas.

My intented target was commons-lang, but this is Java6.

 

Where could I propose the helpers?`

 

 

Jan

[RNG] Scope of "Commons RNG"

[Gilles]

Hello.

This is a post to ask about what we want "Commons RNG"
to be (as a service to the users).

In the Wikipedia pages referred to in the following
reports
  https://issues.apache.org/jira/browse/RNG-16
  https://issues.apache.org/jira/browse/RNG-17
the take-away message (IIUC) is that LCG and LFG are
almost never to be used.[1]

If we want "Commons RNG" to be a repository of all
generators that exist out there, irrespective of their
known weaknesses, it's fine; but we should be careful to
not let casual users just pick one of the implementations
on the premise that the library focuses on high quality
generators.

On the other hand, we could be wary of adding code[2]
that we'd then recommend to not use...

If, from some POV, it is deemed useful to have those,
the scope and overview of the component should mention,
prominently, the "caveat".[3]

I have no issue with adding any new implementation,[4]
on the conditions that it comes with
 1. a unit test where the output (say, a few hundred
numbers) of "Commons RNG" is compared against a
"reference" implementation,[5]
 2. the outputs of the "RandomStressTester"[6] piping
from the "Dieharder" and "TU01/BigCrush" actual
stress test suites.[7]

We should add a note to that effect somewhere in the
documentation, perhaps in "CONTRIBUTING.md" (?).

Regards,
Gilles

[1] Emmanuel, if you don't mind, we'd thus set the JIRA
issue "type" to "wish" rather than "improvement".
[2] https://xkcd.com/221/
[3] Up to now, I had assumed that no known-to-be-bad
generators would be part of "Commons RNG" (except
"JDK", for reference purposes).
[4] It is not a problem to wait another couple of weeks
for the additional code, before releasing 1.0.
[5] I.e. _not_ a "pre-run" of the same implementation!
[6] Source is in "src/userguide/java".
[7] Those software have to be installed separately.


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

Re: commons-io git commit: Remove redundant type arguments.

[Benedikt Ritter]

Hi Gary,

is you line ending set up correct? See
https://help.github.com/articles/dealing-with-line-endings/

Can you please revert the commit and then commit only the stuff you wanted
to change?

Thank you!
Benedikt

Gary Gregory  schrieb am Di., 20. Sep. 2016 um
17:01 Uhr:

> This annoying :-( it must be an EOL thing.
>
> Gary
>
> On Sep 20, 2016 7:18 AM, "Matt Sicker"  wrote:
>
> > Did the line ending change?
> >
> > On 20 September 2016 at 01:59, Benedikt Ritter 
> wrote:
> >
> > > Hello Gary,
> > >
> > > why has the whole file changed?
> > >
> > > Regards,
> > > Benedikt
> > >
> > >  schrieb am Di., 20. Sep. 2016 um 07:40 Uhr:
> > >
> > > > Repository: commons-io
> > > > Updated Branches:
> > > >   refs/heads/master 9ba9b49af -> 822bd135f
> > > >
> > > >
> > > > Remove redundant type arguments.
> > > >
> > > > Project: http://git-wip-us.apache.org/repos/asf/commons-io/repo
> > > > Commit: http://git-wip-us.apache.org/repos/asf/commons-io/commit/
> > > 822bd135
> > > > Tree:
> http://git-wip-us.apache.org/repos/asf/commons-io/tree/822bd135
> > > > Diff:
> http://git-wip-us.apache.org/repos/asf/commons-io/diff/822bd135
> > > >
> > > > Branch: refs/heads/master
> > > > Commit: 822bd135f3a54b8fbeb23c313535b13c18198c3a
> > > > Parents: 9ba9b49
> > > > Author: Gary Gregory 
> > > > Authored: Mon Sep 19 22:40:29 2016 -0700
> > > > Committer: Gary Gregory 
> > > > Committed: Mon Sep 19 22:40:29 2016 -0700
> > > >
> > > >
> --
> > > >  .../commons/io/input/ObservableInputStream.java | 476
> > > +--
> > > >  1 file changed, 238 insertions(+), 238 deletions(-)
> > > >
> --
> > > >
> > > >
> > > >
> > > > http://git-wip-us.apache.org/repos/asf/commons-io/blob/
> > > 822bd135/src/main/java/org/apache/commons/io/input/
> > > ObservableInputStream.java
> > > >
> --
> > > > diff --git
> > > >
> a/src/main/java/org/apache/commons/io/input/ObservableInputStream.java
> > > >
> b/src/main/java/org/apache/commons/io/input/ObservableInputStream.java
> > > > index 7d13472..c580ba4 100644
> > > > --- a/src/main/java/org/apache/commons/io/input/
> > > ObservableInputStream.java
> > > > +++ b/src/main/java/org/apache/commons/io/input/
> > > ObservableInputStream.java
> > > > @@ -1,238 +1,238 @@
> > > > -/*
> > > > - * Licensed to the Apache Software Foundation (ASF) under one or
> more
> > > > - * contributor license agreements.  See the NOTICE file distributed
> > with
> > > > - * this work for additional information regarding copyright
> ownership.
> > > > - * The ASF licenses this file to You under the Apache License,
> Version
> > > 2.0
> > > > - * (the "License"); you may not use this file except in compliance
> > with
> > > > - * the License.  You may obtain a copy of the License at
> > > > - *
> > > > - *  http://www.apache.org/licenses/LICENSE-2.0
> > > > - *
> > > > - * Unless required by applicable law or agreed to in writing,
> software
> > > > - * distributed under the License is distributed on an "AS IS" BASIS,
> > > > - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > > > implied.
> > > > - * See the License for the specific language governing permissions
> and
> > > > - * limitations under the License.
> > > > - */
> > > > -package org.apache.commons.io.input;
> > > > -
> > > > -import java.io.IOException;
> > > > -import java.io.InputStream;
> > > > -import java.security.MessageDigest;
> > > > -import java.util.ArrayList;
> > > > -import java.util.List;
> > > > -
> > > > -
> > > > -/**
> > > > - * The {@link ObservableInputStream} allows, that an InputStream may
> > be
> > > > consumed
> > > > - * by other receivers, apart from the thread, which is reading it.
> > > > - * The other consumers are implemented as instances of {@link
> > > Observer}. A
> > > > - * typical application may be the generation of a {@link
> > MessageDigest}
> > > > on the
> > > > - * fly.
> > > > - * {@code Note}: The {@link ObservableInputStream} is not
> > > thread
> > > > safe,
> > > > - * as instances of InputStream usually aren't.
> > > > - * If you must access the stream from multiple threads, then
> > > > synchronization, locking,
> > > > - * or a similar means must be used.
> > > > - * @see MessageDigestCalculatingInputStream
> > > > - */
> > > > -public class ObservableInputStream extends ProxyInputStream {
> > > > -public static abstract class Observer {
> > > > -/** Called to indicate, that {@link InputStream#read()} has
> > been
> > > > invoked
> > > > - * on the {@link ObservableInputStream}, and will return a
> > > value.
> > > > - * @param pByte The value, which is being returned. This
> will
> > > > never be -1 (EOF),
> > > > -   

Re: [LANG] Towards 3.5

[Benedikt Ritter]

Hi,

just wanted to give you an update. I have the day of on Saturday and I will
prepare 3.5 RC1 then. So now is your last chance to get your stuff into
this release :-)

Regards,
Benedikt

Gary Gregory  schrieb am So., 11. Sep. 2016 um
19:55 Uhr:

> On Sun, Sep 11, 2016 at 9:36 AM, Benedikt Ritter 
> wrote:
>
> > Hello again,
> >
> > Benedikt Ritter  schrieb am So., 11. Sep. 2016 um
> > 15:44 Uhr:
> >
> > > Hi,
> > >
> > > please share your thoughts about LANG-1134 [1]. I argue that it is not
> > > ready to be shipped with 3.5.
> > >
> >
> > Furthermore we need to fix LANG-1264 [2] IMHO.
> >
>
> +1
>
> Gary
>
> >
> > Benedikt
> >
> > [2] https://issues.apache.org/jira/browse/LANG-1264
> >
> >
> > > Regards,
> > > Benedikt
> > >
> > > [1] https://issues.apache.org/jira/browse/LANG-1134
> > >
> > >
> > > Benedikt Ritter  schrieb am Sa., 10. Sep. 2016 um
> > > 20:59 Uhr:
> > >
> > >> Hi,
> > >>
> > >> I'm going to start preparation for release 3.5 tomorrow. If there is
> > >> anything you like to have included, please fix it now.
> > >>
> > >> Regards,
> > >> 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
>

Re: [LANG] Things to look for when working on LANG

[Benedikt Ritter]

Pascal Schumacher  schrieb am Di., 20. Sep. 2016
um 18:23 Uhr:

> +1
>
> Is it possible to enable the javadoc check on travis-ci, so that it is
> also done for any pull request?
>

Yes, that would probably require a custome script hook in .travis.yml. Once
we have cleaned up the findbugs, pmd and checkstyle reports we can also add
those if we want to.

Benedikt


>
> Thanks,
> Pascal
>
> Am 19.09.2016 um 13:26 schrieb Benedikt Ritter:
> > Hi,
> >
> > I'm currently going through the code base to polish it for 3.5. There are
> > some things every developer should have a look for so that it is less
> work
> > to prepare a new release:
> >
> > - always add a @since tag when introducing new methods
> > - make sure the site build still works. I' ve added javadoc:javadoc to
> the
> > jenkins build so that it will fail if the JavaDoc is malformed
> > - keep an eye on FindBugs, PMD, checkstyle. You can generate the complete
> > site by running mvn site
> >
> > Thank you,
> > Benedikt
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>