AW: AW: [RNG] Help with Jenkins

[jhm]

> https://builds.apache.org/view/Apache%20Commons/job/Commons_Rng/77/org
> > .apache.commons$commons-rng-examples/console
> 
>  From what I read in the "configure" page of the Jenkins interface, it
> is not possible for a module to override the settings of the "parent"
> configuration!
> Hence I don't see how Jenkins can be used to check the different
> settings (Java 6 vs Java 7) of the modules's respective POM's...

Some ideas:
Use different Jenkins jobs for different Java versions.

Use different Maven profiles which sets a property for the config path and is 
activated by specific Java version.


Jan


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

Jenkins build is back to stable : commons-io » Apache Commons IO #16

[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 stable : commons-io » Apache Commons IO #16

[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 became unstable: commons-io #15

[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 became unstable: commons-io » Apache Commons IO #15

[Apache Jenkins Server]

See 


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

Re: [LANG] Feedback from ApacheCON Europe

[Thiago Andrade]

I vote mainly for the use of

- Custom annotations
- Put the information right into the JavaDoc is also useful but I think
that maybe some indication on the name of the class might be a good idea too

On Sat, Nov 19, 2016 at 6:52 AM, Benedikt Ritter  wrote:

> Hi,
>
> after my presentation about Apache Commons, there where some comments about
> [lang]. One person said, that it is hard to find out whether our classes
> are threadsafe or not. He would like to see that better documented.
>
> I know that sebb has done some work in that direction, but as far as I know
> the information about thread safety is currently only in Java comments.
>
> How can we improve our docs with regards to thread safety? I see several
> ways:
> - Custom annotations like @Immutable, @ThreadSafe, @NotThreadSafe
> - Custom JavaDoc doclets
> - Put the information right into the JavaDoc
>
> Anything else?
>
> Benedikt
>



-- 
Thiago Andrade

MSc in Computer Science, UFPE – Brazil
BSc in Computer Engineering, UPE – Brazil

Re: [LANG] Feedback from ApacheCON Europe

[Gary Gregory]

On Tue, Nov 22, 2016 at 4:08 PM, Gary Gregory 
wrote:

> On Tue, Nov 22, 2016 at 4:04 PM, Gary Gregory 
> wrote:
>
>> An interesting question is whether we should provide a copy of the
>> annotations scoped as RUNTIME, which was the original way the code was
>> published out of the JCIP book.
>>
>> For our use case within Commons, we want a CLASS or SOURCE level
>> dependency. We do not want RUNTIME because we do not want a hard dependency
>> on Commons Lang from other Commons components.
>>
>
> http://pastebin.com/RKPGGdJ9 adds the "classic" four
> javax.annotation.concurrent annotations to two packages (.clazz and
> .runtime) in Commons Lang for CLASS and RUNTIME retentions.
>

I suppose we would need to add ASL headers to these.

Gary


> Gary
>
>
>>
>> Gary
>>
>> On Tue, Nov 22, 2016 at 2:23 PM, Gary Gregory 
>> wrote:
>>
>>> It would if the Google version or ours is signed. It also would be a
>>> problem if we used a different retention level from Google's.
>>>
>>> Maybe using our own in o.a.c.lang3 would be less confusing all around.
>>>
>>> Gary
>>>
>>> On Tue, Nov 22, 2016 at 2:15 PM, Matt Sicker  wrote:
>>>
 Would packaging them in the JSR package name inside commons lang cause
 classpath issues if you include the google copy?

 On 22 November 2016 at 15:53, Gary Gregory 
 wrote:

 > Should we:
 >
 > - package these (three) annotations per the JSR package name, or,
 > - in o.a.c.lang3, or,
 > - should we depend on a jar like
 > https://search.maven.org/#artifactdetails%7Ccom.google.
 > code.findbugs%7Cjsr305%7C3.0.1%7Cjar
 >
 > ?
 >
 > Gary
 >
 > On Tue, Nov 22, 2016 at 1:47 PM, Matt Sicker 
 wrote:
 >
 > > It's at least pretty standard (being a JSR and all), plus no runtime
 > > dependency, I don't see why not!
 > >
 > > On 22 November 2016 at 15:36, Gary Gregory 
 > wrote:
 > >
 > > > Maybe we could start with adding these three annotations to
 [lang] with
 > > > Class retention which does not create a runtime dependency. Then
 we can
 > > use
 > > > them all over Commons.
 > > >
 > > > WDYT?
 > > >
 > > > Gary
 > > >
 > > > On Tue, Nov 22, 2016 at 11:39 AM, Benedikt Ritter <
 brit...@apache.org>
 > > > wrote:
 > > >
 > > > > Hello,
 > > > >
 > > > > Gary Gregory  schrieb am So., 20. Nov.
 2016
 > um
 > > > > 16:50 Uhr:
 > > > >
 > > > > > Let's recognize that these annotations can give you a false
 sense
 > of
 > > > > > confidence, you still should read at least the docs and
 probably
 > the
 > > > code
 > > > > > if you REALLY care about thread safety.
 > > > > >
 > > > >
 > > > > I thought about this again today on my way to work and came up
 with
 > the
 > > > > same conclusion.
 > > > >
 > > > >
 > > > > >
 > > > > > There will be mistakes in documentation where the wrong or
 > > > contradictory
 > > > > > annotation will split in and/or will be out of sync with
 Javadocs.
 > At
 > > > > least
 > > > > > that's what is likely to happen _over time_.
 > > > > >
 > > > >
 > > > > agreed.
 > > > >
 > > > >
 > > > > >
 > > > > > IOW, its a nice idea but not a panacea for actual thread
 safety.
 > > > > >
 > > > >
 > > > > agreed.
 > > > >
 > > > >
 > > > > >
 > > > > > The other issue is that if we are serious about this we are
 going
 > to
 > > > end
 > > > > up
 > > > > > with the same annotations in all Commons packages. We could
 reuse
 > > > > > javax.annotation.concurrent from JSR 305 as published in
 > > > > >
 > > > > > https://search.maven.org/#artifactdetails%7Ccom.google.
 > > > > code.findbugs%7Cjsr305%7C3.0.1%7Cjar
 > > > > > (CLASS level retention).
 > > > > >
 > > > >
 > > > > The logical conclusion from your comments above would imply to
 put
 > some
 > > > > tests or static code analysis in place which can verify whether
 the
 > > real
 > > > > thread safety properties match the documented ones. I'm not
 aware of
 > > any
 > > > > tool which can do that.
 > > > >
 > > > > So maybe should rather document why we don't document thread
 safety
 > :-)
 > > > >
 > > > > Benedikt
 > > > >
 > > > >
 > > > > >
 > > > > > Gary
 > > > > >
 > > > > > On Sat, Nov 19, 2016 at 3:52 AM, Benedikt Ritter <
 > brit...@apache.org
 > > >
 > > > > > wrote:
 > > > > >
 > > > > > > Hi,
 > > > > > >
 > > > > > > after my presentation about Apache Commons, there where some
 > > comments
 > > > > > about
 

Re: [LANG] Feedback from ApacheCON Europe

[Gary Gregory]

On Tue, Nov 22, 2016 at 4:04 PM, Gary Gregory 
wrote:

> An interesting question is whether we should provide a copy of the
> annotations scoped as RUNTIME, which was the original way the code was
> published out of the JCIP book.
>
> For our use case within Commons, we want a CLASS or SOURCE level
> dependency. We do not want RUNTIME because we do not want a hard dependency
> on Commons Lang from other Commons components.
>

http://pastebin.com/RKPGGdJ9 adds the "classic" four
javax.annotation.concurrent annotations to two packages (.clazz and
.runtime) in Commons Lang for CLASS and RUNTIME retentions.

Gary


>
> Gary
>
> On Tue, Nov 22, 2016 at 2:23 PM, Gary Gregory 
> wrote:
>
>> It would if the Google version or ours is signed. It also would be a
>> problem if we used a different retention level from Google's.
>>
>> Maybe using our own in o.a.c.lang3 would be less confusing all around.
>>
>> Gary
>>
>> On Tue, Nov 22, 2016 at 2:15 PM, Matt Sicker  wrote:
>>
>>> Would packaging them in the JSR package name inside commons lang cause
>>> classpath issues if you include the google copy?
>>>
>>> On 22 November 2016 at 15:53, Gary Gregory 
>>> wrote:
>>>
>>> > Should we:
>>> >
>>> > - package these (three) annotations per the JSR package name, or,
>>> > - in o.a.c.lang3, or,
>>> > - should we depend on a jar like
>>> > https://search.maven.org/#artifactdetails%7Ccom.google.
>>> > code.findbugs%7Cjsr305%7C3.0.1%7Cjar
>>> >
>>> > ?
>>> >
>>> > Gary
>>> >
>>> > On Tue, Nov 22, 2016 at 1:47 PM, Matt Sicker  wrote:
>>> >
>>> > > It's at least pretty standard (being a JSR and all), plus no runtime
>>> > > dependency, I don't see why not!
>>> > >
>>> > > On 22 November 2016 at 15:36, Gary Gregory 
>>> > wrote:
>>> > >
>>> > > > Maybe we could start with adding these three annotations to [lang]
>>> with
>>> > > > Class retention which does not create a runtime dependency. Then
>>> we can
>>> > > use
>>> > > > them all over Commons.
>>> > > >
>>> > > > WDYT?
>>> > > >
>>> > > > Gary
>>> > > >
>>> > > > On Tue, Nov 22, 2016 at 11:39 AM, Benedikt Ritter <
>>> brit...@apache.org>
>>> > > > wrote:
>>> > > >
>>> > > > > Hello,
>>> > > > >
>>> > > > > Gary Gregory  schrieb am So., 20. Nov.
>>> 2016
>>> > um
>>> > > > > 16:50 Uhr:
>>> > > > >
>>> > > > > > Let's recognize that these annotations can give you a false
>>> sense
>>> > of
>>> > > > > > confidence, you still should read at least the docs and
>>> probably
>>> > the
>>> > > > code
>>> > > > > > if you REALLY care about thread safety.
>>> > > > > >
>>> > > > >
>>> > > > > I thought about this again today on my way to work and came up
>>> with
>>> > the
>>> > > > > same conclusion.
>>> > > > >
>>> > > > >
>>> > > > > >
>>> > > > > > There will be mistakes in documentation where the wrong or
>>> > > > contradictory
>>> > > > > > annotation will split in and/or will be out of sync with
>>> Javadocs.
>>> > At
>>> > > > > least
>>> > > > > > that's what is likely to happen _over time_.
>>> > > > > >
>>> > > > >
>>> > > > > agreed.
>>> > > > >
>>> > > > >
>>> > > > > >
>>> > > > > > IOW, its a nice idea but not a panacea for actual thread
>>> safety.
>>> > > > > >
>>> > > > >
>>> > > > > agreed.
>>> > > > >
>>> > > > >
>>> > > > > >
>>> > > > > > The other issue is that if we are serious about this we are
>>> going
>>> > to
>>> > > > end
>>> > > > > up
>>> > > > > > with the same annotations in all Commons packages. We could
>>> reuse
>>> > > > > > javax.annotation.concurrent from JSR 305 as published in
>>> > > > > >
>>> > > > > > https://search.maven.org/#artifactdetails%7Ccom.google.
>>> > > > > code.findbugs%7Cjsr305%7C3.0.1%7Cjar
>>> > > > > > (CLASS level retention).
>>> > > > > >
>>> > > > >
>>> > > > > The logical conclusion from your comments above would imply to
>>> put
>>> > some
>>> > > > > tests or static code analysis in place which can verify whether
>>> the
>>> > > real
>>> > > > > thread safety properties match the documented ones. I'm not
>>> aware of
>>> > > any
>>> > > > > tool which can do that.
>>> > > > >
>>> > > > > So maybe should rather document why we don't document thread
>>> safety
>>> > :-)
>>> > > > >
>>> > > > > Benedikt
>>> > > > >
>>> > > > >
>>> > > > > >
>>> > > > > > Gary
>>> > > > > >
>>> > > > > > On Sat, Nov 19, 2016 at 3:52 AM, Benedikt Ritter <
>>> > brit...@apache.org
>>> > > >
>>> > > > > > wrote:
>>> > > > > >
>>> > > > > > > Hi,
>>> > > > > > >
>>> > > > > > > after my presentation about Apache Commons, there where some
>>> > > comments
>>> > > > > > about
>>> > > > > > > [lang]. One person said, that it is hard to find out whether
>>> our
>>> > > > > classes
>>> > > > > > > are threadsafe or not. He would like to see that better
>>> > documented.
>>> > > > > > >
>>> > > > > > > I know that sebb has done some work in that direction, but
>>> as far
>>> > > as
>>> > > > I

Re: [LANG] Feedback from ApacheCON Europe

[Gary Gregory]

An interesting question is whether we should provide a copy of the
annotations scoped as RUNTIME, which was the original way the code was
published out of the JCIP book.

For our use case within Commons, we want a CLASS or SOURCE level
dependency. We do not want RUNTIME because we do not want a hard dependency
on Commons Lang from other Commons components.

Gary

On Tue, Nov 22, 2016 at 2:23 PM, Gary Gregory 
wrote:

> It would if the Google version or ours is signed. It also would be a
> problem if we used a different retention level from Google's.
>
> Maybe using our own in o.a.c.lang3 would be less confusing all around.
>
> Gary
>
> On Tue, Nov 22, 2016 at 2:15 PM, Matt Sicker  wrote:
>
>> Would packaging them in the JSR package name inside commons lang cause
>> classpath issues if you include the google copy?
>>
>> On 22 November 2016 at 15:53, Gary Gregory 
>> wrote:
>>
>> > Should we:
>> >
>> > - package these (three) annotations per the JSR package name, or,
>> > - in o.a.c.lang3, or,
>> > - should we depend on a jar like
>> > https://search.maven.org/#artifactdetails%7Ccom.google.
>> > code.findbugs%7Cjsr305%7C3.0.1%7Cjar
>> >
>> > ?
>> >
>> > Gary
>> >
>> > On Tue, Nov 22, 2016 at 1:47 PM, Matt Sicker  wrote:
>> >
>> > > It's at least pretty standard (being a JSR and all), plus no runtime
>> > > dependency, I don't see why not!
>> > >
>> > > On 22 November 2016 at 15:36, Gary Gregory 
>> > wrote:
>> > >
>> > > > Maybe we could start with adding these three annotations to [lang]
>> with
>> > > > Class retention which does not create a runtime dependency. Then we
>> can
>> > > use
>> > > > them all over Commons.
>> > > >
>> > > > WDYT?
>> > > >
>> > > > Gary
>> > > >
>> > > > On Tue, Nov 22, 2016 at 11:39 AM, Benedikt Ritter <
>> brit...@apache.org>
>> > > > wrote:
>> > > >
>> > > > > Hello,
>> > > > >
>> > > > > Gary Gregory  schrieb am So., 20. Nov.
>> 2016
>> > um
>> > > > > 16:50 Uhr:
>> > > > >
>> > > > > > Let's recognize that these annotations can give you a false
>> sense
>> > of
>> > > > > > confidence, you still should read at least the docs and probably
>> > the
>> > > > code
>> > > > > > if you REALLY care about thread safety.
>> > > > > >
>> > > > >
>> > > > > I thought about this again today on my way to work and came up
>> with
>> > the
>> > > > > same conclusion.
>> > > > >
>> > > > >
>> > > > > >
>> > > > > > There will be mistakes in documentation where the wrong or
>> > > > contradictory
>> > > > > > annotation will split in and/or will be out of sync with
>> Javadocs.
>> > At
>> > > > > least
>> > > > > > that's what is likely to happen _over time_.
>> > > > > >
>> > > > >
>> > > > > agreed.
>> > > > >
>> > > > >
>> > > > > >
>> > > > > > IOW, its a nice idea but not a panacea for actual thread safety.
>> > > > > >
>> > > > >
>> > > > > agreed.
>> > > > >
>> > > > >
>> > > > > >
>> > > > > > The other issue is that if we are serious about this we are
>> going
>> > to
>> > > > end
>> > > > > up
>> > > > > > with the same annotations in all Commons packages. We could
>> reuse
>> > > > > > javax.annotation.concurrent from JSR 305 as published in
>> > > > > >
>> > > > > > https://search.maven.org/#artifactdetails%7Ccom.google.
>> > > > > code.findbugs%7Cjsr305%7C3.0.1%7Cjar
>> > > > > > (CLASS level retention).
>> > > > > >
>> > > > >
>> > > > > The logical conclusion from your comments above would imply to put
>> > some
>> > > > > tests or static code analysis in place which can verify whether
>> the
>> > > real
>> > > > > thread safety properties match the documented ones. I'm not aware
>> of
>> > > any
>> > > > > tool which can do that.
>> > > > >
>> > > > > So maybe should rather document why we don't document thread
>> safety
>> > :-)
>> > > > >
>> > > > > Benedikt
>> > > > >
>> > > > >
>> > > > > >
>> > > > > > Gary
>> > > > > >
>> > > > > > On Sat, Nov 19, 2016 at 3:52 AM, Benedikt Ritter <
>> > brit...@apache.org
>> > > >
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > after my presentation about Apache Commons, there where some
>> > > comments
>> > > > > > about
>> > > > > > > [lang]. One person said, that it is hard to find out whether
>> our
>> > > > > classes
>> > > > > > > are threadsafe or not. He would like to see that better
>> > documented.
>> > > > > > >
>> > > > > > > I know that sebb has done some work in that direction, but as
>> far
>> > > as
>> > > > I
>> > > > > > know
>> > > > > > > the information about thread safety is currently only in Java
>> > > > comments.
>> > > > > > >
>> > > > > > > How can we improve our docs with regards to thread safety? I
>> see
>> > > > > several
>> > > > > > > ways:
>> > > > > > > - Custom annotations like @Immutable, @ThreadSafe,
>> @NotThreadSafe
>> > > > > > > - Custom JavaDoc doclets
>> > > > > > > - Put the information right into the JavaDoc
>> > > > > > >
>> 

Re: AW: [RNG] Help with Jenkins

[Gilles]

On Tue, 22 Nov 2016 21:38:58 +0100, Gilles wrote:

[...]


Havent found something in the job config.
Maven is started with
"clean deploy --batch-mode -Dgpg.skip -Prelease -Pjava-1.6
-DJAVA_1_6_HOME=$JDK_1_6_LATEST__HOME pmd:pmd findbugs:findbugs
checkstyle:checkstyle"



This is the problem I was referring to in the previous message:


https://builds.apache.org/view/Apache%20Commons/job/Commons_Rng/77/org.apache.commons$commons-rng-examples/console


From what I read in the "configure" page of the Jenkins interface,
it is not possible for a module to override the settings of the
"parent" configuration!
Hence I don't see how Jenkins can be used to check the different
settings (Java 6 vs Java 7) of the modules's respective POM's...

Regards,
Gilles



Regards,
Gilles


Jan


-Ursprüngliche Nachricht-
Von: Gilles [mailto:gil...@harfang.homelinux.org]
Gesendet: Dienstag, 22. November 2016 13:18
An: dev@commons.apache.org
Betreff: Re: [RNG] Help with Jenkins

Hi.

On Tue, 22 Nov 2016 15:47:16 +1100, Olivier Lamy wrote:
> fixed

Thanks for taking care, but it doesn't look like it is fixed:
   https://builds.apache.org/view/Apache%20Commons/job/Commons_RNG/

Best regards,
Gilles

>
> On 22 November 2016 at 09:51, Gilles 


> wrote:
>
>> Hi.
>>
>> Jenkins fails because the POM of the "commons-rng-examples"
>> (correctly) requires Java 1.7 while the Jenkins job config uses 
the

>> 1.6 maven profile.[1]
>>
>> Does someone know how to fix that?
>>
>>
>> Thanks,
>> Gilles
>>
>> [1] See "Goals and options" at
>>   
https://builds.apache.org/view/Apache%20Commons/job/Commons_

>> Rng/configure
>>
>>



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

Re: [LANG] Feedback from ApacheCON Europe

[Gary Gregory]

It would if the Google version or ours is signed. It also would be a
problem if we used a different retention level from Google's.

Maybe using our own in o.a.c.lang3 would be less confusing all around.

Gary

On Tue, Nov 22, 2016 at 2:15 PM, Matt Sicker  wrote:

> Would packaging them in the JSR package name inside commons lang cause
> classpath issues if you include the google copy?
>
> On 22 November 2016 at 15:53, Gary Gregory  wrote:
>
> > Should we:
> >
> > - package these (three) annotations per the JSR package name, or,
> > - in o.a.c.lang3, or,
> > - should we depend on a jar like
> > https://search.maven.org/#artifactdetails%7Ccom.google.
> > code.findbugs%7Cjsr305%7C3.0.1%7Cjar
> >
> > ?
> >
> > Gary
> >
> > On Tue, Nov 22, 2016 at 1:47 PM, Matt Sicker  wrote:
> >
> > > It's at least pretty standard (being a JSR and all), plus no runtime
> > > dependency, I don't see why not!
> > >
> > > On 22 November 2016 at 15:36, Gary Gregory 
> > wrote:
> > >
> > > > Maybe we could start with adding these three annotations to [lang]
> with
> > > > Class retention which does not create a runtime dependency. Then we
> can
> > > use
> > > > them all over Commons.
> > > >
> > > > WDYT?
> > > >
> > > > Gary
> > > >
> > > > On Tue, Nov 22, 2016 at 11:39 AM, Benedikt Ritter <
> brit...@apache.org>
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Gary Gregory  schrieb am So., 20. Nov.
> 2016
> > um
> > > > > 16:50 Uhr:
> > > > >
> > > > > > Let's recognize that these annotations can give you a false sense
> > of
> > > > > > confidence, you still should read at least the docs and probably
> > the
> > > > code
> > > > > > if you REALLY care about thread safety.
> > > > > >
> > > > >
> > > > > I thought about this again today on my way to work and came up with
> > the
> > > > > same conclusion.
> > > > >
> > > > >
> > > > > >
> > > > > > There will be mistakes in documentation where the wrong or
> > > > contradictory
> > > > > > annotation will split in and/or will be out of sync with
> Javadocs.
> > At
> > > > > least
> > > > > > that's what is likely to happen _over time_.
> > > > > >
> > > > >
> > > > > agreed.
> > > > >
> > > > >
> > > > > >
> > > > > > IOW, its a nice idea but not a panacea for actual thread safety.
> > > > > >
> > > > >
> > > > > agreed.
> > > > >
> > > > >
> > > > > >
> > > > > > The other issue is that if we are serious about this we are going
> > to
> > > > end
> > > > > up
> > > > > > with the same annotations in all Commons packages. We could reuse
> > > > > > javax.annotation.concurrent from JSR 305 as published in
> > > > > >
> > > > > > https://search.maven.org/#artifactdetails%7Ccom.google.
> > > > > code.findbugs%7Cjsr305%7C3.0.1%7Cjar
> > > > > > (CLASS level retention).
> > > > > >
> > > > >
> > > > > The logical conclusion from your comments above would imply to put
> > some
> > > > > tests or static code analysis in place which can verify whether the
> > > real
> > > > > thread safety properties match the documented ones. I'm not aware
> of
> > > any
> > > > > tool which can do that.
> > > > >
> > > > > So maybe should rather document why we don't document thread safety
> > :-)
> > > > >
> > > > > Benedikt
> > > > >
> > > > >
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > On Sat, Nov 19, 2016 at 3:52 AM, Benedikt Ritter <
> > brit...@apache.org
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > after my presentation about Apache Commons, there where some
> > > comments
> > > > > > about
> > > > > > > [lang]. One person said, that it is hard to find out whether
> our
> > > > > classes
> > > > > > > are threadsafe or not. He would like to see that better
> > documented.
> > > > > > >
> > > > > > > I know that sebb has done some work in that direction, but as
> far
> > > as
> > > > I
> > > > > > know
> > > > > > > the information about thread safety is currently only in Java
> > > > comments.
> > > > > > >
> > > > > > > How can we improve our docs with regards to thread safety? I
> see
> > > > > several
> > > > > > > ways:
> > > > > > > - Custom annotations like @Immutable, @ThreadSafe,
> @NotThreadSafe
> > > > > > > - Custom JavaDoc doclets
> > > > > > > - Put the information right into the JavaDoc
> > > > > > >
> > > > > > > Anything else?
> > > > > > >
> > > > > > > Benedikt
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > > > > Java Persistence with Hibernate, Second Edition
> > > > > > <
> > > > > > https://www.amazon.com/gp/product/1617290459/ref=as_li_
> > > > > tl?ie=UTF8=1789=9325=1617290459&
> > > > > linkCode=as2=garygregory-20=
> > cadb800f39946ec62ea2b1af9fe6a2
> > > b8
> > > > > > >
> > > > > >
> > > > > >  > > > > > ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1&
> > > a=1617290459
> > > > >
> > > > > > JUnit 

Re: [LANG] Feedback from ApacheCON Europe

[Matt Sicker]

Would packaging them in the JSR package name inside commons lang cause
classpath issues if you include the google copy?

On 22 November 2016 at 15:53, Gary Gregory  wrote:

> Should we:
>
> - package these (three) annotations per the JSR package name, or,
> - in o.a.c.lang3, or,
> - should we depend on a jar like
> https://search.maven.org/#artifactdetails%7Ccom.google.
> code.findbugs%7Cjsr305%7C3.0.1%7Cjar
>
> ?
>
> Gary
>
> On Tue, Nov 22, 2016 at 1:47 PM, Matt Sicker  wrote:
>
> > It's at least pretty standard (being a JSR and all), plus no runtime
> > dependency, I don't see why not!
> >
> > On 22 November 2016 at 15:36, Gary Gregory 
> wrote:
> >
> > > Maybe we could start with adding these three annotations to [lang] with
> > > Class retention which does not create a runtime dependency. Then we can
> > use
> > > them all over Commons.
> > >
> > > WDYT?
> > >
> > > Gary
> > >
> > > On Tue, Nov 22, 2016 at 11:39 AM, Benedikt Ritter 
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > Gary Gregory  schrieb am So., 20. Nov. 2016
> um
> > > > 16:50 Uhr:
> > > >
> > > > > Let's recognize that these annotations can give you a false sense
> of
> > > > > confidence, you still should read at least the docs and probably
> the
> > > code
> > > > > if you REALLY care about thread safety.
> > > > >
> > > >
> > > > I thought about this again today on my way to work and came up with
> the
> > > > same conclusion.
> > > >
> > > >
> > > > >
> > > > > There will be mistakes in documentation where the wrong or
> > > contradictory
> > > > > annotation will split in and/or will be out of sync with Javadocs.
> At
> > > > least
> > > > > that's what is likely to happen _over time_.
> > > > >
> > > >
> > > > agreed.
> > > >
> > > >
> > > > >
> > > > > IOW, its a nice idea but not a panacea for actual thread safety.
> > > > >
> > > >
> > > > agreed.
> > > >
> > > >
> > > > >
> > > > > The other issue is that if we are serious about this we are going
> to
> > > end
> > > > up
> > > > > with the same annotations in all Commons packages. We could reuse
> > > > > javax.annotation.concurrent from JSR 305 as published in
> > > > >
> > > > > https://search.maven.org/#artifactdetails%7Ccom.google.
> > > > code.findbugs%7Cjsr305%7C3.0.1%7Cjar
> > > > > (CLASS level retention).
> > > > >
> > > >
> > > > The logical conclusion from your comments above would imply to put
> some
> > > > tests or static code analysis in place which can verify whether the
> > real
> > > > thread safety properties match the documented ones. I'm not aware of
> > any
> > > > tool which can do that.
> > > >
> > > > So maybe should rather document why we don't document thread safety
> :-)
> > > >
> > > > Benedikt
> > > >
> > > >
> > > > >
> > > > > Gary
> > > > >
> > > > > On Sat, Nov 19, 2016 at 3:52 AM, Benedikt Ritter <
> brit...@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > after my presentation about Apache Commons, there where some
> > comments
> > > > > about
> > > > > > [lang]. One person said, that it is hard to find out whether our
> > > > classes
> > > > > > are threadsafe or not. He would like to see that better
> documented.
> > > > > >
> > > > > > I know that sebb has done some work in that direction, but as far
> > as
> > > I
> > > > > know
> > > > > > the information about thread safety is currently only in Java
> > > comments.
> > > > > >
> > > > > > How can we improve our docs with regards to thread safety? I see
> > > > several
> > > > > > ways:
> > > > > > - Custom annotations like @Immutable, @ThreadSafe, @NotThreadSafe
> > > > > > - Custom JavaDoc doclets
> > > > > > - Put the information right into the JavaDoc
> > > > > >
> > > > > > Anything else?
> > > > > >
> > > > > > Benedikt
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > > > Java Persistence with Hibernate, Second Edition
> > > > > <
> > > > > https://www.amazon.com/gp/product/1617290459/ref=as_li_
> > > > tl?ie=UTF8=1789=9325=1617290459&
> > > > linkCode=as2=garygregory-20=
> cadb800f39946ec62ea2b1af9fe6a2
> > b8
> > > > > >
> > > > >
> > > > >  > > > > ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1&
> > a=1617290459
> > > >
> > > > > JUnit in Action, Second Edition
> > > > > <
> > > > > https://www.amazon.com/gp/product/1935182021/ref=as_li_
> > > > tl?ie=UTF8=1789=9325=1935182021&
> > > > linkCode=as2=garygregory-20=
> 31ecd1f6b6d1eaf8886ac902a24de4
> > > 18%22
> > > > > >
> > > > >
> > > > >  > > > > ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1&
> > a=1935182021
> > > >
> > > > > Spring Batch in Action
> > > > > <
> > > > > https://www.amazon.com/gp/product/1935182951/ref=as_li_
> > > > tl?ie=UTF8=1789=9325=1935182951&
> > > > linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> > > > 

[ANNOUNCEMENT] Apache Commons Build Plugin 1.7

[Gary Gregory]

[Not cross posted to @announce since this is internal to Commons]

Apache Commons has released the Apache Commons Build Plugin 1.7.

The Apache Commons Build Plugin is a Maven Plugin which can be used by
Apache Commons components.

See:
   http://commons.apache.org/commons-build-plugin/


VERSION 1.7 - 2016-11-18


Changes since the last release
1. Include badges in the README.md file.  Issue: COMMONSSITE-90.
2. Build plugin does not pass the JIRA_ID property when generating
README.md.  Issue: COMMONSSITE-91.

Gary

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



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [LANG] Feedback from ApacheCON Europe

[Gary Gregory]

Should we:

- package these (three) annotations per the JSR package name, or,
- in o.a.c.lang3, or,
- should we depend on a jar like
https://search.maven.org/#artifactdetails%7Ccom.google.code.findbugs%7Cjsr305%7C3.0.1%7Cjar

?

Gary

On Tue, Nov 22, 2016 at 1:47 PM, Matt Sicker  wrote:

> It's at least pretty standard (being a JSR and all), plus no runtime
> dependency, I don't see why not!
>
> On 22 November 2016 at 15:36, Gary Gregory  wrote:
>
> > Maybe we could start with adding these three annotations to [lang] with
> > Class retention which does not create a runtime dependency. Then we can
> use
> > them all over Commons.
> >
> > WDYT?
> >
> > Gary
> >
> > On Tue, Nov 22, 2016 at 11:39 AM, Benedikt Ritter 
> > wrote:
> >
> > > Hello,
> > >
> > > Gary Gregory  schrieb am So., 20. Nov. 2016 um
> > > 16:50 Uhr:
> > >
> > > > Let's recognize that these annotations can give you a false sense of
> > > > confidence, you still should read at least the docs and probably the
> > code
> > > > if you REALLY care about thread safety.
> > > >
> > >
> > > I thought about this again today on my way to work and came up with the
> > > same conclusion.
> > >
> > >
> > > >
> > > > There will be mistakes in documentation where the wrong or
> > contradictory
> > > > annotation will split in and/or will be out of sync with Javadocs. At
> > > least
> > > > that's what is likely to happen _over time_.
> > > >
> > >
> > > agreed.
> > >
> > >
> > > >
> > > > IOW, its a nice idea but not a panacea for actual thread safety.
> > > >
> > >
> > > agreed.
> > >
> > >
> > > >
> > > > The other issue is that if we are serious about this we are going to
> > end
> > > up
> > > > with the same annotations in all Commons packages. We could reuse
> > > > javax.annotation.concurrent from JSR 305 as published in
> > > >
> > > > https://search.maven.org/#artifactdetails%7Ccom.google.
> > > code.findbugs%7Cjsr305%7C3.0.1%7Cjar
> > > > (CLASS level retention).
> > > >
> > >
> > > The logical conclusion from your comments above would imply to put some
> > > tests or static code analysis in place which can verify whether the
> real
> > > thread safety properties match the documented ones. I'm not aware of
> any
> > > tool which can do that.
> > >
> > > So maybe should rather document why we don't document thread safety :-)
> > >
> > > Benedikt
> > >
> > >
> > > >
> > > > Gary
> > > >
> > > > On Sat, Nov 19, 2016 at 3:52 AM, Benedikt Ritter  >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > after my presentation about Apache Commons, there where some
> comments
> > > > about
> > > > > [lang]. One person said, that it is hard to find out whether our
> > > classes
> > > > > are threadsafe or not. He would like to see that better documented.
> > > > >
> > > > > I know that sebb has done some work in that direction, but as far
> as
> > I
> > > > know
> > > > > the information about thread safety is currently only in Java
> > comments.
> > > > >
> > > > > How can we improve our docs with regards to thread safety? I see
> > > several
> > > > > ways:
> > > > > - Custom annotations like @Immutable, @ThreadSafe, @NotThreadSafe
> > > > > - Custom JavaDoc doclets
> > > > > - Put the information right into the JavaDoc
> > > > >
> > > > > Anything else?
> > > > >
> > > > > Benedikt
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > > Java Persistence with Hibernate, Second Edition
> > > > <
> > > > https://www.amazon.com/gp/product/1617290459/ref=as_li_
> > > tl?ie=UTF8=1789=9325=1617290459&
> > > linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2
> b8
> > > > >
> > > >
> > > >  > > > ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1&
> a=1617290459
> > >
> > > > JUnit in Action, Second Edition
> > > > <
> > > > https://www.amazon.com/gp/product/1935182021/ref=as_li_
> > > tl?ie=UTF8=1789=9325=1935182021&
> > > linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de4
> > 18%22
> > > > >
> > > >
> > > >  > > > ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1&
> a=1935182021
> > >
> > > > Spring Batch in Action
> > > > <
> > > > https://www.amazon.com/gp/product/1935182951/ref=as_li_
> > > tl?ie=UTF8=1789=9325=1935182951&
> > > linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> > > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action
> > > > >
> > > >  > > > ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1&
> a=1935182951
> > >
> > > > Blog: http://garygregory.wordpress.com
> > > > Home: http://garygregory.com/
> > > > Tweet! http://twitter.com/GaryGregory
> > > >
> > >
> >
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> >  > tl?ie=UTF8=1789=9325=1617290459&
> > 

Re: [LANG] Feedback from ApacheCON Europe

[Matt Sicker]

It's at least pretty standard (being a JSR and all), plus no runtime
dependency, I don't see why not!

On 22 November 2016 at 15:36, Gary Gregory  wrote:

> Maybe we could start with adding these three annotations to [lang] with
> Class retention which does not create a runtime dependency. Then we can use
> them all over Commons.
>
> WDYT?
>
> Gary
>
> On Tue, Nov 22, 2016 at 11:39 AM, Benedikt Ritter 
> wrote:
>
> > Hello,
> >
> > Gary Gregory  schrieb am So., 20. Nov. 2016 um
> > 16:50 Uhr:
> >
> > > Let's recognize that these annotations can give you a false sense of
> > > confidence, you still should read at least the docs and probably the
> code
> > > if you REALLY care about thread safety.
> > >
> >
> > I thought about this again today on my way to work and came up with the
> > same conclusion.
> >
> >
> > >
> > > There will be mistakes in documentation where the wrong or
> contradictory
> > > annotation will split in and/or will be out of sync with Javadocs. At
> > least
> > > that's what is likely to happen _over time_.
> > >
> >
> > agreed.
> >
> >
> > >
> > > IOW, its a nice idea but not a panacea for actual thread safety.
> > >
> >
> > agreed.
> >
> >
> > >
> > > The other issue is that if we are serious about this we are going to
> end
> > up
> > > with the same annotations in all Commons packages. We could reuse
> > > javax.annotation.concurrent from JSR 305 as published in
> > >
> > > https://search.maven.org/#artifactdetails%7Ccom.google.
> > code.findbugs%7Cjsr305%7C3.0.1%7Cjar
> > > (CLASS level retention).
> > >
> >
> > The logical conclusion from your comments above would imply to put some
> > tests or static code analysis in place which can verify whether the real
> > thread safety properties match the documented ones. I'm not aware of any
> > tool which can do that.
> >
> > So maybe should rather document why we don't document thread safety :-)
> >
> > Benedikt
> >
> >
> > >
> > > Gary
> > >
> > > On Sat, Nov 19, 2016 at 3:52 AM, Benedikt Ritter 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > after my presentation about Apache Commons, there where some comments
> > > about
> > > > [lang]. One person said, that it is hard to find out whether our
> > classes
> > > > are threadsafe or not. He would like to see that better documented.
> > > >
> > > > I know that sebb has done some work in that direction, but as far as
> I
> > > know
> > > > the information about thread safety is currently only in Java
> comments.
> > > >
> > > > How can we improve our docs with regards to thread safety? I see
> > several
> > > > ways:
> > > > - Custom annotations like @Immutable, @ThreadSafe, @NotThreadSafe
> > > > - Custom JavaDoc doclets
> > > > - Put the information right into the JavaDoc
> > > >
> > > > Anything else?
> > > >
> > > > Benedikt
> > > >
> > >
> > >
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > Java Persistence with Hibernate, Second Edition
> > > <
> > > https://www.amazon.com/gp/product/1617290459/ref=as_li_
> > tl?ie=UTF8=1789=9325=1617290459&
> > linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8
> > > >
> > >
> > >  > > ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1617290459
> >
> > > JUnit in Action, Second Edition
> > > <
> > > https://www.amazon.com/gp/product/1935182021/ref=as_li_
> > tl?ie=UTF8=1789=9325=1935182021&
> > linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de4
> 18%22
> > > >
> > >
> > >  > > ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182021
> >
> > > Spring Batch in Action
> > > <
> > > https://www.amazon.com/gp/product/1935182951/ref=as_li_
> > tl?ie=UTF8=1789=9325=1935182951&
> > linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action
> > > >
> > >  > > ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182951
> >
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
>  tl?ie=UTF8=1789=9325=1617290459&
> linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>
>  1617290459>
> JUnit in Action, Second Edition
>  tl?ie=UTF8=1789=9325=1935182021&
> linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
>  1935182021>
> Spring Batch in Action
>  tl?ie=UTF8=1789=9325=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> 

Re: [text][lang] string escaping

[Gary Gregory]

On Tue, Nov 22, 2016 at 12:04 PM, Benedikt Ritter 
wrote:

> Hello Gilles
>
> Gilles  schrieb am Di., 22. Nov. 2016 um
> 20:55 Uhr:
>
> > On Tue, 22 Nov 2016 19:40:30 +, Benedikt Ritter wrote:
> > > Gary Gregory  schrieb am Sa., 19. Nov. 2016
> > > um
> > > 19:09 Uhr:
> > >
> > >> On Nov 19, 2016 9:50 AM, "Gilles" 
> > >> wrote:
> > >> >
> > >> > On Sat, 19 Nov 2016 08:59:50 -0800, Gary Gregory wrote:
> > >> >>
> > >> >> On Sat, Nov 19, 2016 at 3:33 AM, Benedikt Ritter
> > >> 
> > >> wrote:
> > >> >>
> > >> >>> Hello Gray,
> > >> >>>
> > >> >>> Gary Gregory  schrieb am Sa., 19. Nov.
> > >> 2016 um
> > >> >>> 01:07 Uhr:
> > >> >>>
> > >> >>> > Just a thought:
> > >> >>> >
> > >> >>> > Does all the current (and future) string escaping code (XML,
> > >> HTML,
> > >> ...)
> > >> >>> > really belong in [lang]? Would it be more natural to have it
> > >> in
> > >> [text]?
> > >> >>> >
> > >> >>>
> > >> >>> My view on the whole think currently is, that we put stuff that
> > >> is
> > >> related
> > >> >>> to strings in Lang. Code that works on texts should go to Text.
> > >> To me a
> > >> >>> text is more than just a string. A text contains works, that
> > >> make up
> > >> >>> sentences, which in turn build paragraphs.
> > >> >>>
> > >> >>> Using this description, I'd argue that escaping belongs into
> > >> lang and
> > >> not
> > >> >>> into text, because it works on individual characters rather than
> > >> on
> > >> texts.
> > >> >>>
> > >> >>> But this would also raise the question if the various edit
> > >> distance
> > >> >>> algorithms works on texts or on strings. So maybe my distinction
> > >> is not
> > >> >>> good at all.
> > >> >>>
> > >> >>> Do we need to better specify the scope of text?
> > >> >>>
> > >> >>
> > >> >> Great question of course.
> > >> >>
> > >> >> I'd like to think of [lang] as "What is missing from the JRE's
> > >> most
> > >> basic
> > >> >> classes and specifically from the java.lang package and some
> > >> java.util
> > >> >> classes".
> > >> >>
> > >> >> Quoting from our site:
> > >> >>
> > >> >> "The standard Java libraries fail to provide enough methods for
> > >> >> manipulation of its core classes. Apache Commons Lang provides
> > >> these
> > >> extra
> > >> >> methods.
> > >> >> Lang provides a host of helper utilities for the java.lang API,
> > >> notably
> > >> >> String manipulation methods, basic numerical methods, object
> > >> reflection,
> > >> >> concurrency, creation and serialization and System properties.
> > >> Additionally
> > >> >> it contains basic enhancements to java.util.Date
> > >> >
> > >> >
> > >> > How about "Date" becoming a nice standalone component? ;-)
> > >> > [Components should be concept-based.]
> > >>
> > >> Joda-time covers more than we will ever do here IMO. And Java 8 has
> > >> new
> > >> time APIs... maybe when lang is Java 8 based we can look again. For
> > >> now I'd
> > >> rather leave dates as is.
> > >>
> > >
> > > Yes, let's get back to topic.
> > >
> > > I think we need a clear distinction between string related stuff that
> > > goes
> > > into Lang and more complex stuff that goes into text.
> >
> > IMHO "more complex" is key, not so much "string" vs "text".
> >
> > Hence I suggest [text] is a better place for "RandomStringUtils"
> > than [lang], and the former should allow dependencies as a
> > foundation for that complexity; in that case, that would be
> > "Commons RNG".
> >
>
> I find it hard to draw a line here. What might be complex to me, could be
> simple for others. I fear that there will always be discussions.
>

Then we can focus on a feature request with a different lens: Would you
reasonably expect this to be in java.lang or java.util.

Gary

>
>
> >
> > Regards,
> > Gilles
> >
> > >
> > >
> > >>
> > >> Gary
> > >> >
> > >> > How about deprecating "RandomUtils"?
> > >> > [(About to be) superseded by "Commons RNG".]
> > >> >
> > >> > How about to
> > >> >  * moving "RandomStringUtils" to [text] too and
> > >> >  * implement it against a custom interface (as per Jochen's
> > >> remark)
> > >> >rather than "java.util.Random"
> > >> > ?
> > >> >
> > >> >
> > >> >> and a series of utilities
> > >> >> dedicated to help with building methods, such as hashCode,
> > >> toString and
> > >> >> equals."
> > >> >>
> > >> >> I do not think edit distances fit into this at all.
> > >> >
> > >> >
> > >> > +1
> > >> >
> > >> >
> > >> >> I am also questioning whether string escaping belongs in lang as
> > >> well
> > >> since
> > >> >> there are so many escaping domains XML, HTML, JSON, and so on.
> > >> >
> > >> >
> > >> > They don't belong.
> > >> >
> > >> >
> > >> >> IMO, anything that is word based does not belong in lang like
> > >> >> capitlization. The WordUtils class should be in [text] IMO. The
> > >> whole
> > >> lang
> > >> >> text package should be in [text] IMO.
> > >> >

Re: [LANG] Feedback from ApacheCON Europe

[Gary Gregory]

Maybe we could start with adding these three annotations to [lang] with
Class retention which does not create a runtime dependency. Then we can use
them all over Commons.

WDYT?

Gary

On Tue, Nov 22, 2016 at 11:39 AM, Benedikt Ritter 
wrote:

> Hello,
>
> Gary Gregory  schrieb am So., 20. Nov. 2016 um
> 16:50 Uhr:
>
> > Let's recognize that these annotations can give you a false sense of
> > confidence, you still should read at least the docs and probably the code
> > if you REALLY care about thread safety.
> >
>
> I thought about this again today on my way to work and came up with the
> same conclusion.
>
>
> >
> > There will be mistakes in documentation where the wrong or contradictory
> > annotation will split in and/or will be out of sync with Javadocs. At
> least
> > that's what is likely to happen _over time_.
> >
>
> agreed.
>
>
> >
> > IOW, its a nice idea but not a panacea for actual thread safety.
> >
>
> agreed.
>
>
> >
> > The other issue is that if we are serious about this we are going to end
> up
> > with the same annotations in all Commons packages. We could reuse
> > javax.annotation.concurrent from JSR 305 as published in
> >
> > https://search.maven.org/#artifactdetails%7Ccom.google.
> code.findbugs%7Cjsr305%7C3.0.1%7Cjar
> > (CLASS level retention).
> >
>
> The logical conclusion from your comments above would imply to put some
> tests or static code analysis in place which can verify whether the real
> thread safety properties match the documented ones. I'm not aware of any
> tool which can do that.
>
> So maybe should rather document why we don't document thread safety :-)
>
> Benedikt
>
>
> >
> > Gary
> >
> > On Sat, Nov 19, 2016 at 3:52 AM, Benedikt Ritter 
> > wrote:
> >
> > > Hi,
> > >
> > > after my presentation about Apache Commons, there where some comments
> > about
> > > [lang]. One person said, that it is hard to find out whether our
> classes
> > > are threadsafe or not. He would like to see that better documented.
> > >
> > > I know that sebb has done some work in that direction, but as far as I
> > know
> > > the information about thread safety is currently only in Java comments.
> > >
> > > How can we improve our docs with regards to thread safety? I see
> several
> > > ways:
> > > - Custom annotations like @Immutable, @ThreadSafe, @NotThreadSafe
> > > - Custom JavaDoc doclets
> > > - Put the information right into the JavaDoc
> > >
> > > Anything else?
> > >
> > > Benedikt
> > >
> >
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> > <
> > https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8=1789=9325=1617290459&
> linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8
> > >
> >
> >  > ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1617290459>
> > JUnit in Action, Second Edition
> > <
> > https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8=1789=9325=1935182021&
> linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22
> > >
> >
> >  > ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182021>
> > Spring Batch in Action
> > <
> > https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8=1789=9325=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action
> > >
> >  > ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182951>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>



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



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: AW: [RNG] Help with Jenkins

[Gilles]

Hi.

On Tue, 22 Nov 2016 16:20:31 +0100, Jan Matèrne wrote:

Could not find resource 'pmd/pmd-ruleset.xml'.


I think I fixed that problem.



Havent found something in the job config.
Maven is started with
"clean deploy --batch-mode -Dgpg.skip -Prelease -Pjava-1.6
-DJAVA_1_6_HOME=$JDK_1_6_LATEST__HOME pmd:pmd findbugs:findbugs
checkstyle:checkstyle"



This is the problem I was referring to in the previous message:
  
https://builds.apache.org/view/Apache%20Commons/job/Commons_Rng/77/org.apache.commons$commons-rng-examples/console



Regards,
Gilles


Jan


-Ursprüngliche Nachricht-
Von: Gilles [mailto:gil...@harfang.homelinux.org]
Gesendet: Dienstag, 22. November 2016 13:18
An: dev@commons.apache.org
Betreff: Re: [RNG] Help with Jenkins

Hi.

On Tue, 22 Nov 2016 15:47:16 +1100, Olivier Lamy wrote:
> fixed

Thanks for taking care, but it doesn't look like it is fixed:
   https://builds.apache.org/view/Apache%20Commons/job/Commons_RNG/

Best regards,
Gilles

>
> On 22 November 2016 at 09:51, Gilles 


> wrote:
>
>> Hi.
>>
>> Jenkins fails because the POM of the "commons-rng-examples"
>> (correctly) requires Java 1.7 while the Jenkins job config uses 
the

>> 1.6 maven profile.[1]
>>
>> Does someone know how to fix that?
>>
>>
>> Thanks,
>> Gilles
>>
>> [1] See "Goals and options" at
>>   
https://builds.apache.org/view/Apache%20Commons/job/Commons_

>> Rng/configure
>>
>>



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

Re: [text][lang] string escaping

[Gilles]

On Tue, 22 Nov 2016 20:04:55 +, Benedikt Ritter wrote:

Hello Gilles

Gilles  schrieb am Di., 22. Nov. 2016 
um

20:55 Uhr:


On Tue, 22 Nov 2016 19:40:30 +, Benedikt Ritter wrote:
> Gary Gregory  schrieb am Sa., 19. Nov. 
2016

> um
> 19:09 Uhr:
>
>> On Nov 19, 2016 9:50 AM, "Gilles" 
>> wrote:
>> >
>> > On Sat, 19 Nov 2016 08:59:50 -0800, Gary Gregory wrote:
>> >>
>> >> On Sat, Nov 19, 2016 at 3:33 AM, Benedikt Ritter
>> 
>> wrote:
>> >>
>> >>> Hello Gray,
>> >>>
>> >>> Gary Gregory  schrieb am Sa., 19. 
Nov.

>> 2016 um
>> >>> 01:07 Uhr:
>> >>>
>> >>> > Just a thought:
>> >>> >
>> >>> > Does all the current (and future) string escaping code 
(XML,

>> HTML,
>> ...)
>> >>> > really belong in [lang]? Would it be more natural to have 
it

>> in
>> [text]?
>> >>> >
>> >>>
>> >>> My view on the whole think currently is, that we put stuff 
that

>> is
>> related
>> >>> to strings in Lang. Code that works on texts should go to 
Text.

>> To me a
>> >>> text is more than just a string. A text contains works, that
>> make up
>> >>> sentences, which in turn build paragraphs.
>> >>>
>> >>> Using this description, I'd argue that escaping belongs into
>> lang and
>> not
>> >>> into text, because it works on individual characters rather 
than

>> on
>> texts.
>> >>>
>> >>> But this would also raise the question if the various edit
>> distance
>> >>> algorithms works on texts or on strings. So maybe my 
distinction

>> is not
>> >>> good at all.
>> >>>
>> >>> Do we need to better specify the scope of text?
>> >>>
>> >>
>> >> Great question of course.
>> >>
>> >> I'd like to think of [lang] as "What is missing from the JRE's
>> most
>> basic
>> >> classes and specifically from the java.lang package and some
>> java.util
>> >> classes".
>> >>
>> >> Quoting from our site:
>> >>
>> >> "The standard Java libraries fail to provide enough methods 
for

>> >> manipulation of its core classes. Apache Commons Lang provides
>> these
>> extra
>> >> methods.
>> >> Lang provides a host of helper utilities for the java.lang 
API,

>> notably
>> >> String manipulation methods, basic numerical methods, object
>> reflection,
>> >> concurrency, creation and serialization and System properties.
>> Additionally
>> >> it contains basic enhancements to java.util.Date
>> >
>> >
>> > How about "Date" becoming a nice standalone component? ;-)
>> > [Components should be concept-based.]
>>
>> Joda-time covers more than we will ever do here IMO. And Java 8 
has

>> new
>> time APIs... maybe when lang is Java 8 based we can look again. 
For

>> now I'd
>> rather leave dates as is.
>>
>
> Yes, let's get back to topic.
>
> I think we need a clear distinction between string related stuff 
that

> goes
> into Lang and more complex stuff that goes into text.

IMHO "more complex" is key, not so much "string" vs "text".

Hence I suggest [text] is a better place for "RandomStringUtils"
than [lang], and the former should allow dependencies as a
foundation for that complexity; in that case, that would be
"Commons RNG".



I find it hard to draw a line here. What might be complex to me, 
could be

simple for others. I fear that there will always be discussions.


The complexity we talk about here should not be subjective.

In particular, discussions would be reduced if a scope is
defined precisely.

Gilles





Regards,
Gilles

>
>
>>
>> Gary
>> >
>> > How about deprecating "RandomUtils"?
>> > [(About to be) superseded by "Commons RNG".]
>> >
>> > How about to
>> >  * moving "RandomStringUtils" to [text] too and
>> >  * implement it against a custom interface (as per Jochen's
>> remark)
>> >rather than "java.util.Random"
>> > ?
>> >
>> >
>> >> and a series of utilities
>> >> dedicated to help with building methods, such as hashCode,
>> toString and
>> >> equals."
>> >>
>> >> I do not think edit distances fit into this at all.
>> >
>> >
>> > +1
>> >
>> >
>> >> I am also questioning whether string escaping belongs in lang 
as

>> well
>> since
>> >> there are so many escaping domains XML, HTML, JSON, and so on.
>> >
>> >
>> > They don't belong.
>> >
>> >
>> >> IMO, anything that is word based does not belong in lang like
>> >> capitlization. The WordUtils class should be in [text] IMO. 
The

>> whole
>> lang
>> >> text package should be in [text] IMO.
>> >
>> >
>> > +1
>> > [To anything that imposes a strict diet on the humongous
>> "components".]
>> >
>> >
>> > Regards,
>> > Gilles
>> >



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

Re: [text][lang] string escaping

[Benedikt Ritter]

Hello Gilles

Gilles  schrieb am Di., 22. Nov. 2016 um
20:55 Uhr:

> On Tue, 22 Nov 2016 19:40:30 +, Benedikt Ritter wrote:
> > Gary Gregory  schrieb am Sa., 19. Nov. 2016
> > um
> > 19:09 Uhr:
> >
> >> On Nov 19, 2016 9:50 AM, "Gilles" 
> >> wrote:
> >> >
> >> > On Sat, 19 Nov 2016 08:59:50 -0800, Gary Gregory wrote:
> >> >>
> >> >> On Sat, Nov 19, 2016 at 3:33 AM, Benedikt Ritter
> >> 
> >> wrote:
> >> >>
> >> >>> Hello Gray,
> >> >>>
> >> >>> Gary Gregory  schrieb am Sa., 19. Nov.
> >> 2016 um
> >> >>> 01:07 Uhr:
> >> >>>
> >> >>> > Just a thought:
> >> >>> >
> >> >>> > Does all the current (and future) string escaping code (XML,
> >> HTML,
> >> ...)
> >> >>> > really belong in [lang]? Would it be more natural to have it
> >> in
> >> [text]?
> >> >>> >
> >> >>>
> >> >>> My view on the whole think currently is, that we put stuff that
> >> is
> >> related
> >> >>> to strings in Lang. Code that works on texts should go to Text.
> >> To me a
> >> >>> text is more than just a string. A text contains works, that
> >> make up
> >> >>> sentences, which in turn build paragraphs.
> >> >>>
> >> >>> Using this description, I'd argue that escaping belongs into
> >> lang and
> >> not
> >> >>> into text, because it works on individual characters rather than
> >> on
> >> texts.
> >> >>>
> >> >>> But this would also raise the question if the various edit
> >> distance
> >> >>> algorithms works on texts or on strings. So maybe my distinction
> >> is not
> >> >>> good at all.
> >> >>>
> >> >>> Do we need to better specify the scope of text?
> >> >>>
> >> >>
> >> >> Great question of course.
> >> >>
> >> >> I'd like to think of [lang] as "What is missing from the JRE's
> >> most
> >> basic
> >> >> classes and specifically from the java.lang package and some
> >> java.util
> >> >> classes".
> >> >>
> >> >> Quoting from our site:
> >> >>
> >> >> "The standard Java libraries fail to provide enough methods for
> >> >> manipulation of its core classes. Apache Commons Lang provides
> >> these
> >> extra
> >> >> methods.
> >> >> Lang provides a host of helper utilities for the java.lang API,
> >> notably
> >> >> String manipulation methods, basic numerical methods, object
> >> reflection,
> >> >> concurrency, creation and serialization and System properties.
> >> Additionally
> >> >> it contains basic enhancements to java.util.Date
> >> >
> >> >
> >> > How about "Date" becoming a nice standalone component? ;-)
> >> > [Components should be concept-based.]
> >>
> >> Joda-time covers more than we will ever do here IMO. And Java 8 has
> >> new
> >> time APIs... maybe when lang is Java 8 based we can look again. For
> >> now I'd
> >> rather leave dates as is.
> >>
> >
> > Yes, let's get back to topic.
> >
> > I think we need a clear distinction between string related stuff that
> > goes
> > into Lang and more complex stuff that goes into text.
>
> IMHO "more complex" is key, not so much "string" vs "text".
>
> Hence I suggest [text] is a better place for "RandomStringUtils"
> than [lang], and the former should allow dependencies as a
> foundation for that complexity; in that case, that would be
> "Commons RNG".
>

I find it hard to draw a line here. What might be complex to me, could be
simple for others. I fear that there will always be discussions.


>
> Regards,
> Gilles
>
> >
> >
> >>
> >> Gary
> >> >
> >> > How about deprecating "RandomUtils"?
> >> > [(About to be) superseded by "Commons RNG".]
> >> >
> >> > How about to
> >> >  * moving "RandomStringUtils" to [text] too and
> >> >  * implement it against a custom interface (as per Jochen's
> >> remark)
> >> >rather than "java.util.Random"
> >> > ?
> >> >
> >> >
> >> >> and a series of utilities
> >> >> dedicated to help with building methods, such as hashCode,
> >> toString and
> >> >> equals."
> >> >>
> >> >> I do not think edit distances fit into this at all.
> >> >
> >> >
> >> > +1
> >> >
> >> >
> >> >> I am also questioning whether string escaping belongs in lang as
> >> well
> >> since
> >> >> there are so many escaping domains XML, HTML, JSON, and so on.
> >> >
> >> >
> >> > They don't belong.
> >> >
> >> >
> >> >> IMO, anything that is word based does not belong in lang like
> >> >> capitlization. The WordUtils class should be in [text] IMO. The
> >> whole
> >> lang
> >> >> text package should be in [text] IMO.
> >> >
> >> >
> >> > +1
> >> > [To anything that imposes a strict diet on the humongous
> >> "components".]
> >> >
> >> >
> >> > Regards,
> >> > Gilles
> >> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [text][lang] string escaping

[Gilles]

On Tue, 22 Nov 2016 19:40:30 +, Benedikt Ritter wrote:
Gary Gregory  schrieb am Sa., 19. Nov. 2016 
um

19:09 Uhr:

On Nov 19, 2016 9:50 AM, "Gilles"  
wrote:

>
> On Sat, 19 Nov 2016 08:59:50 -0800, Gary Gregory wrote:
>>
>> On Sat, Nov 19, 2016 at 3:33 AM, Benedikt Ritter 


wrote:
>>
>>> Hello Gray,
>>>
>>> Gary Gregory  schrieb am Sa., 19. Nov. 
2016 um

>>> 01:07 Uhr:
>>>
>>> > Just a thought:
>>> >
>>> > Does all the current (and future) string escaping code (XML, 
HTML,

...)
>>> > really belong in [lang]? Would it be more natural to have it 
in

[text]?
>>> >
>>>
>>> My view on the whole think currently is, that we put stuff that 
is

related
>>> to strings in Lang. Code that works on texts should go to Text. 
To me a
>>> text is more than just a string. A text contains works, that 
make up

>>> sentences, which in turn build paragraphs.
>>>
>>> Using this description, I'd argue that escaping belongs into 
lang and

not
>>> into text, because it works on individual characters rather than 
on

texts.
>>>
>>> But this would also raise the question if the various edit 
distance
>>> algorithms works on texts or on strings. So maybe my distinction 
is not

>>> good at all.
>>>
>>> Do we need to better specify the scope of text?
>>>
>>
>> Great question of course.
>>
>> I'd like to think of [lang] as "What is missing from the JRE's 
most

basic
>> classes and specifically from the java.lang package and some 
java.util

>> classes".
>>
>> Quoting from our site:
>>
>> "The standard Java libraries fail to provide enough methods for
>> manipulation of its core classes. Apache Commons Lang provides 
these

extra
>> methods.
>> Lang provides a host of helper utilities for the java.lang API, 
notably
>> String manipulation methods, basic numerical methods, object 
reflection,

>> concurrency, creation and serialization and System properties.
Additionally
>> it contains basic enhancements to java.util.Date
>
>
> How about "Date" becoming a nice standalone component? ;-)
> [Components should be concept-based.]

Joda-time covers more than we will ever do here IMO. And Java 8 has 
new
time APIs... maybe when lang is Java 8 based we can look again. For 
now I'd

rather leave dates as is.



Yes, let's get back to topic.

I think we need a clear distinction between string related stuff that 
goes

into Lang and more complex stuff that goes into text.


IMHO "more complex" is key, not so much "string" vs "text".

Hence I suggest [text] is a better place for "RandomStringUtils"
than [lang], and the former should allow dependencies as a
foundation for that complexity; in that case, that would be
"Commons RNG".

Regards,
Gilles






Gary
>
> How about deprecating "RandomUtils"?
> [(About to be) superseded by "Commons RNG".]
>
> How about to
>  * moving "RandomStringUtils" to [text] too and
>  * implement it against a custom interface (as per Jochen's 
remark)

>rather than "java.util.Random"
> ?
>
>
>> and a series of utilities
>> dedicated to help with building methods, such as hashCode, 
toString and

>> equals."
>>
>> I do not think edit distances fit into this at all.
>
>
> +1
>
>
>> I am also questioning whether string escaping belongs in lang as 
well

since
>> there are so many escaping domains XML, HTML, JSON, and so on.
>
>
> They don't belong.
>
>
>> IMO, anything that is word based does not belong in lang like
>> capitlization. The WordUtils class should be in [text] IMO. The 
whole

lang
>> text package should be in [text] IMO.
>
>
> +1
> [To anything that imposes a strict diet on the humongous 
"components".]

>
>
> Regards,
> Gilles
>



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

Re: [text][lang] string escaping

[Benedikt Ritter]

Gary Gregory  schrieb am Sa., 19. Nov. 2016 um
19:09 Uhr:

> On Nov 19, 2016 9:50 AM, "Gilles"  wrote:
> >
> > On Sat, 19 Nov 2016 08:59:50 -0800, Gary Gregory wrote:
> >>
> >> On Sat, Nov 19, 2016 at 3:33 AM, Benedikt Ritter 
> wrote:
> >>
> >>> Hello Gray,
> >>>
> >>> Gary Gregory  schrieb am Sa., 19. Nov. 2016 um
> >>> 01:07 Uhr:
> >>>
> >>> > Just a thought:
> >>> >
> >>> > Does all the current (and future) string escaping code (XML, HTML,
> ...)
> >>> > really belong in [lang]? Would it be more natural to have it in
> [text]?
> >>> >
> >>>
> >>> My view on the whole think currently is, that we put stuff that is
> related
> >>> to strings in Lang. Code that works on texts should go to Text. To me a
> >>> text is more than just a string. A text contains works, that make up
> >>> sentences, which in turn build paragraphs.
> >>>
> >>> Using this description, I'd argue that escaping belongs into lang and
> not
> >>> into text, because it works on individual characters rather than on
> texts.
> >>>
> >>> But this would also raise the question if the various edit distance
> >>> algorithms works on texts or on strings. So maybe my distinction is not
> >>> good at all.
> >>>
> >>> Do we need to better specify the scope of text?
> >>>
> >>
> >> Great question of course.
> >>
> >> I'd like to think of [lang] as "What is missing from the JRE's most
> basic
> >> classes and specifically from the java.lang package and some java.util
> >> classes".
> >>
> >> Quoting from our site:
> >>
> >> "The standard Java libraries fail to provide enough methods for
> >> manipulation of its core classes. Apache Commons Lang provides these
> extra
> >> methods.
> >> Lang provides a host of helper utilities for the java.lang API, notably
> >> String manipulation methods, basic numerical methods, object reflection,
> >> concurrency, creation and serialization and System properties.
> Additionally
> >> it contains basic enhancements to java.util.Date
> >
> >
> > How about "Date" becoming a nice standalone component? ;-)
> > [Components should be concept-based.]
>
> Joda-time covers more than we will ever do here IMO. And Java 8 has new
> time APIs... maybe when lang is Java 8 based we can look again. For now I'd
> rather leave dates as is.
>

Yes, let's get back to topic.

I think we need a clear distinction between string related stuff that goes
into Lang and more complex stuff that goes into text.


>
> Gary
> >
> > How about deprecating "RandomUtils"?
> > [(About to be) superseded by "Commons RNG".]
> >
> > How about to
> >  * moving "RandomStringUtils" to [text] too and
> >  * implement it against a custom interface (as per Jochen's remark)
> >rather than "java.util.Random"
> > ?
> >
> >
> >> and a series of utilities
> >> dedicated to help with building methods, such as hashCode, toString and
> >> equals."
> >>
> >> I do not think edit distances fit into this at all.
> >
> >
> > +1
> >
> >
> >> I am also questioning whether string escaping belongs in lang as well
> since
> >> there are so many escaping domains XML, HTML, JSON, and so on.
> >
> >
> > They don't belong.
> >
> >
> >> IMO, anything that is word based does not belong in lang like
> >> capitlization. The WordUtils class should be in [text] IMO. The whole
> lang
> >> text package should be in [text] IMO.
> >
> >
> > +1
> > [To anything that imposes a strict diet on the humongous "components".]
> >
> >
> > Regards,
> > Gilles
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>

Re: [LANG] Feedback from ApacheCON Europe

[Benedikt Ritter]

Hello,

Gary Gregory  schrieb am So., 20. Nov. 2016 um
16:50 Uhr:

> Let's recognize that these annotations can give you a false sense of
> confidence, you still should read at least the docs and probably the code
> if you REALLY care about thread safety.
>

I thought about this again today on my way to work and came up with the
same conclusion.


>
> There will be mistakes in documentation where the wrong or contradictory
> annotation will split in and/or will be out of sync with Javadocs. At least
> that's what is likely to happen _over time_.
>

agreed.


>
> IOW, its a nice idea but not a panacea for actual thread safety.
>

agreed.


>
> The other issue is that if we are serious about this we are going to end up
> with the same annotations in all Commons packages. We could reuse
> javax.annotation.concurrent from JSR 305 as published in
>
> https://search.maven.org/#artifactdetails%7Ccom.google.code.findbugs%7Cjsr305%7C3.0.1%7Cjar
> (CLASS level retention).
>

The logical conclusion from your comments above would imply to put some
tests or static code analysis in place which can verify whether the real
thread safety properties match the documented ones. I'm not aware of any
tool which can do that.

So maybe should rather document why we don't document thread safety :-)

Benedikt


>
> Gary
>
> On Sat, Nov 19, 2016 at 3:52 AM, Benedikt Ritter 
> wrote:
>
> > Hi,
> >
> > after my presentation about Apache Commons, there where some comments
> about
> > [lang]. One person said, that it is hard to find out whether our classes
> > are threadsafe or not. He would like to see that better documented.
> >
> > I know that sebb has done some work in that direction, but as far as I
> know
> > the information about thread safety is currently only in Java comments.
> >
> > How can we improve our docs with regards to thread safety? I see several
> > ways:
> > - Custom annotations like @Immutable, @ThreadSafe, @NotThreadSafe
> > - Custom JavaDoc doclets
> > - Put the information right into the JavaDoc
> >
> > Anything else?
> >
> > Benedikt
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <
> https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8=1789=9325=1617290459=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8
> >
>
>  ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1617290459>
> JUnit in Action, Second Edition
> <
> https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8=1789=9325=1935182021=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
>  ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182021>
> Spring Batch in Action
> <
> https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8=1789=9325=1935182951=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action
> >
>  ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: [CRYPTO] Feedback from ApacheCON Europe

[Benedikt Ritter]

Hello Dapeng,

Sun, Dapeng  schrieb am Mo., 21. Nov. 2016 um
03:12 Uhr:

> Thank Benedikt for the minutes! And thank Xianda for the presentation.
>

Can you share your thoughts regarding the comments 1) & 2) we got from the
audience? (see below)

Thank you!
Benedikt


>
> -Original Message-
> From: Benedikt Ritter [mailto:brit...@apache.org]
> Sent: Saturday, November 19, 2016 7:49 PM
> To: Commons Developers List 
> Subject: [CRYPTO] Feedback from ApacheCON Europe
>
> Hi,
>
> Xianda Ke held a nice presentation about Commons Crypto yesterday at
> ApacheCON Europe in Seville. Kudos to Xianda Ke and Dapeng Sun for
> preparing the presentation and making the long trip to Europe.
>
> Here are the comments we got from the audience:
>
> 1) Why does Commons Crypto implement it's own Crypto API instead of
> providing a JCE provider?
> If it is possible to write an adapter to JCE, I think this would be a good
> improvement for 1.1. If it is not possible for technical reasons, we should
> document it on the website.
>
> 2) Is it possible to stub in a custom secret generator? There where
> concerns in the audience with regards to the hardware secret generator
> build into the Intel chips, because it is not clear what is happening
> inside that chips.
> Can we extend the API in a why so that users can provide their own secret
> generator? Does this even make sense or will that degrade the performance
> of Crypto?
>
> Regards,
> Benedikt
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

Re: AW: [RNG] Help with Jenkins

[Gilles]

On Tue, 22 Nov 2016 16:20:31 +0100, Jan Matèrne wrote:

Could not find resource 'pmd/pmd-ruleset.xml'.


in the POM, is it necessary to have the plugin declared both
in the  target and in the  target?



Havent found something in the job config.
Maven is started with
"clean deploy --batch-mode -Dgpg.skip -Prelease -Pjava-1.6
-DJAVA_1_6_HOME=$JDK_1_6_LATEST__HOME pmd:pmd findbugs:findbugs
checkstyle:checkstyle"


Yes.
The problem is that it must be possible to build the modules
with different source levels (following what's in the POM[1]),
while the above forces (IIUC) 1.6 for all of them.


Regards,
Gilles






Jan


-Ursprüngliche Nachricht-
Von: Gilles [mailto:gil...@harfang.homelinux.org]
Gesendet: Dienstag, 22. November 2016 13:18
An: dev@commons.apache.org
Betreff: Re: [RNG] Help with Jenkins

Hi.

On Tue, 22 Nov 2016 15:47:16 +1100, Olivier Lamy wrote:
> fixed

Thanks for taking care, but it doesn't look like it is fixed:
   https://builds.apache.org/view/Apache%20Commons/job/Commons_RNG/

Best regards,
Gilles

>
> On 22 November 2016 at 09:51, Gilles 


> wrote:
>
>> Hi.
>>
>> Jenkins fails because the POM of the "commons-rng-examples"
>> (correctly) requires Java 1.7 while the Jenkins job config uses 
the

>> 1.6 maven profile.[1]
>>
>> Does someone know how to fix that?
>>
>>
>> Thanks,
>> Gilles
>>
>> [1] See "Goals and options" at
>>   
https://builds.apache.org/view/Apache%20Commons/job/Commons_

>> Rng/configure
>>
>>



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

AW: [RNG] Help with Jenkins

[jhm]

Could not find resource 'pmd/pmd-ruleset.xml'.


Havent found something in the job config.
Maven is started with
"clean deploy --batch-mode -Dgpg.skip -Prelease -Pjava-1.6 
-DJAVA_1_6_HOME=$JDK_1_6_LATEST__HOME pmd:pmd findbugs:findbugs 
checkstyle:checkstyle"



Jan

> -Ursprüngliche Nachricht-
> Von: Gilles [mailto:gil...@harfang.homelinux.org]
> Gesendet: Dienstag, 22. November 2016 13:18
> An: dev@commons.apache.org
> Betreff: Re: [RNG] Help with Jenkins
> 
> Hi.
> 
> On Tue, 22 Nov 2016 15:47:16 +1100, Olivier Lamy wrote:
> > fixed
> 
> Thanks for taking care, but it doesn't look like it is fixed:
>https://builds.apache.org/view/Apache%20Commons/job/Commons_RNG/
> 
> Best regards,
> Gilles
> 
> >
> > On 22 November 2016 at 09:51, Gilles 
> > wrote:
> >
> >> Hi.
> >>
> >> Jenkins fails because the POM of the "commons-rng-examples"
> >> (correctly) requires Java 1.7 while the Jenkins job config uses the
> >> 1.6 maven profile.[1]
> >>
> >> Does someone know how to fix that?
> >>
> >>
> >> Thanks,
> >> Gilles
> >>
> >> [1] See "Goals and options" at
> >>   https://builds.apache.org/view/Apache%20Commons/job/Commons_
> >> Rng/configure
> >>
> >>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org



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

Re: [RNG] Help with Jenkins

[Gilles]

Hi.

On Tue, 22 Nov 2016 15:47:16 +1100, Olivier Lamy wrote:

fixed


Thanks for taking care, but it doesn't look like it is fixed:
  https://builds.apache.org/view/Apache%20Commons/job/Commons_RNG/

Best regards,
Gilles



On 22 November 2016 at 09:51, Gilles  
wrote:



Hi.

Jenkins fails because the POM of the "commons-rng-examples"
(correctly) requires Java 1.7 while the Jenkins job config
uses the 1.6 maven profile.[1]

Does someone know how to fix that?


Thanks,
Gilles

[1] See "Goals and options" at
  https://builds.apache.org/view/Apache%20Commons/job/Commons_
Rng/configure





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

[GitHub] commons-io pull request #17: Added resourceToString, resourceToByteArray, an...

[behrangsa]

Github user behrangsa closed the pull request at:

https://github.com/apache/commons-io/pull/17


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-io pull request #28: IO-513 - Added convenience methods for loading ...

[behrangsa]

GitHub user behrangsa opened a pull request:

https://github.com/apache/commons-io/pull/28

IO-513 - Added convenience methods for loading resources (original PR: #17)

Added convenience methods for loading resources:

* `resourceToString`
* `resourceToByteArray`
* `resourceToURL`

Original PR: https://github.com/apache/commons-io/pull/17

JIRA Issue: https://issues.apache.org/jira/browse/IO-513

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/behrangsa/commons-io master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-io/pull/28.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #28


commit 421c345667c3538b23d7be4a818b170fa6e168fa
Author: Behrang Saeedzadeh 
Date:   2016-11-22T10:37:51Z

Added convenience methods for loading resources:

* resourceToString
* resourceToByteArray
* resourceToURL




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [RNG] Build succeeds locally but fails on Travis-CI

[Jörg Schaible]

Hi Sebb,

sebb wrote:

> Surely the commons build plugin is only needed to simplify setting up
> some files?
> 
> If it were not there, the files could still be updated manually.
> 
> The doc page [1] makes it clear that the only _potential_ build-time
> dependency is the copy-javadoc-files goal.
> However AFAIK that is not used anywhere.
> 
> So it is not actually used at build time currently.
> 
> [1] http://commons.apache.org/proper/commons-build-plugin/index.html

Actually it does not matter. It is deployed to central normally, so you 
*could* use it at build time independently whether it makes currently sense 
or not.

We could achieve the same with these configuration resources that are used 
by the plugins in the build process of commons-rng and that are possibly 
interesting for other components, too. Do we have shared (copied) 
configuration files (currently for checkstyle, clirr, and pmd) between the 
different components and do we want to share them physically?

Cheers,
Jörg


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

Re: [RNG] Build succeeds locally but fails on Travis-CI

[sebb]

Surely the commons build plugin is only needed to simplify setting up
some files?

If it were not there, the files could still be updated manually.

The doc page [1] makes it clear that the only _potential_ build-time
dependency is the copy-javadoc-files goal.
However AFAIK that is not used anywhere.

So it is not actually used at build time currently.

[1] http://commons.apache.org/proper/commons-build-plugin/index.html


On 22 November 2016 at 07:29, Jörg Schaible
 wrote:
> Hi Gary,
>
> Gary Gregory wrote:
>
>> I was thinking the parent POM just had stuff that needed to be inherited
>> but since I have not looked it sounds like there is actual code in there?
>
> Just ressources, but they are referenced in the plugins' classpaths.
>
>> I am about to push a new version of commons-build-plugin. Is that what you
>> are referring to?
>
> Yes and no. Yes for the release procedure and no for the component itself.
> Look into svn, there's also an old commons-build.
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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