Re: [RDF] Graduating Commons RDF to Commons PMC

Hi, On Wed, Nov 30, 2016 at 4:58 AM, Matt Sicker wrote: > Is there anything to be done for jira? Well, that's a question I also had. So far we have been using COMMONSRDF as Jira key. All the current components simply use the component name a key [1] (e.g., LANG). I already

Re: [lang] Thread safety annotations

Oh that's a pretty decent advantage there actually. On 29 November 2016 at 22:07, Gary Gregory wrote: > On Tue, Nov 29, 2016 at 8:04 PM, Matt Sicker wrote: > > > That's pretty neat. So it looks like two competing styles of annotations > > here would be

Re: [lang] Thread safety annotations

On Tue, Nov 29, 2016 at 8:04 PM, Matt Sicker wrote: > That's pretty neat. So it looks like two competing styles of annotations > here would be separate annotations for each concern, a single annotation > with an enum, or even separate annotations with boolean values or enums >

Re: [lang] Thread safety annotations

That's pretty neat. So it looks like two competing styles of annotations here would be separate annotations for each concern, a single annotation with an enum, or even separate annotations with boolean values or enums (though that gets a little more complex come to think of it). If only the JDK

Re: [RDF] Graduating Commons RDF to Commons PMC

Is there anything to be done for jira? Also, don't forget to update the scm URLs in the pom file. On 28 November 2016 at 05:35, Stian Soiland-Reyes wrote: > The Commons RDF graduation vote passed on Commons and Incubator, so > Commons RDF will now formally move to become a

Re: [ALL] Version number(s) for modular components

What if a feature was added to the maven-release-plugin to release a subset of submodules? I wonder how feasible that would be. On 28 November 2016 at 19:00, Jörg Schaible wrote: > Gilles wrote: > > > On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote: > >> Gilles, > >> >

Re: [complex][math-util] dependencies

On Tue, Nov 29, 2016 at 5:19 AM, Eric Barnhill wrote: > I thought it would be good to raise a structural question here rather than > in the commons-complex JIRA. > > The Complex library has multiple dependencies on three packages: > > -- commons-math base classes (e.g.

Re: [lang] Thread safety annotations

And an example: /** * HTTP/2 compatible extension of {@link RequestConnControl}. * * @since 5.0 */ @Contract(threading = ThreadingBehavior.IMMUTABLE) public class H2RequestConnControl extends RequestConnControl { ... Gary On Tue, Nov 29, 2016 at 6:40 PM, Gary Gregory

Re: [lang] Thread safety annotations

FYI, this is how we're going to do it in HttpComponents 5: https://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore5/src/main/java/org/apache/hc/core5/annotation/ThreadingBehavior.java Gary On Tue, Nov 29, 2016 at 2:20 PM, Gary Gregory wrote: > On Tue,

[GitHub] commons-fileupload issue #5: Update DiskFileItem.java: Avoiding NPE when not...

Github user garydgregory commented on the issue: https://github.com/apache/commons-fileupload/pull/5 Don't you still get an NPE if you call DiskFileItem.isInMemory()? You should really have one @Test method for each DiskFileItem method you modified to show where NPEs have

[VOTE][RC5] Release "Apache Commons RNG" version 1.0

Hi. This is a [VOTE] for releasing Apache Commons RNG 1.0 (from RC5). Main changes wrt the preceding vote (RC2, on September 16) are: * Modularization * Non-uniform deviates (in module "commons-rng-sampling") Tag name: RNG_1_0_RC5 (signature can be checked from git using 'git tag -v')

Re: [lang] Thread safety annotations

On Tue, Nov 29, 2016 at 1:59 PM, Benedikt Ritter wrote: > I agree with Oliver. I don't think we have consensus about if and how we > want to implement this. Does it even make sense to try to document this? > What value does such a documentation have, when it is wrong 50% of

Re: [text] Next steps.

> On Nov 29, 2016, at 2:02 PM, Benedikt Ritter wrote: > > +1 for an early release without the name parser. We can implement the > algorithms from the book in 1.1. Sounds good I’ll start heading that direction. -Rob > > Benedikt > > Gary Gregory

Re: [text] Next steps.

+1 for an early release without the name parser. We can implement the algorithms from the book in 1.1. Benedikt Gary Gregory schrieb am Di. 29. Nov. 2016 um 00:34: > +1 to removing the human name code for 1.0. Put it in a branch IMO. > > Gary > > On Mon, Nov 28, 2016 at

Re: [lang] Thread safety annotations

I agree with Oliver. I don't think we have consensus about if and how we want to implement this. Does it even make sense to try to document this? What value does such a documentation have, when it is wrong 50% of the time? I just sumed up the feedback I got from one (!) user at the conference. I

Re: [lang] Thread safety annotations

On Tue, Nov 29, 2016 at 1:12 PM, Oliver Heger wrote: > > > Am 28.11.2016 um 22:28 schrieb Gary Gregory: > > WRT licensing, I re-implemented the annotations in git master. Notice > that > > all Javadocs are different and much simpler for now. Feel free to write > >

Re: [complex][math-util] dependencies

On Tue, 29 Nov 2016 12:26:53 -0800, Gary Gregory wrote: On Tue, Nov 29, 2016 at 11:39 AM, Jörg Schaible wrote: Hi Eric, Eric Barnhill wrote: > I thought it would be good to raise a structural question here rather than > in the commons-complex JIRA. > > The Complex

Re: [lang] Thread safety annotations

Am 28.11.2016 um 22:28 schrieb Gary Gregory: > WRT licensing, I re-implemented the annotations in git master. Notice that > all Javadocs are different and much simpler for now. Feel free to write > more. As the length of this thread shows, using annotations for the purpose of documenting

Re: [complex][math-util] dependencies

On Tue, Nov 29, 2016 at 11:39 AM, Jörg Schaible wrote: > Hi Eric, > > Eric Barnhill wrote: > > > I thought it would be good to raise a structural question here rather > than > > in the commons-complex JIRA. > > > > The Complex library has multiple dependencies on three

Re: [complex][math-util] dependencies

On Tue, Nov 29, 2016 at 5:19 AM, Eric Barnhill wrote: > I thought it would be good to raise a structural question here rather than > in the commons-complex JIRA. > > The Complex library has multiple dependencies on three packages: > > -- commons-math base classes (e.g.

Re: [complex][math-util] dependencies

Hello Eric. On Tue, 29 Nov 2016 14:19:54 +0100, Eric Barnhill wrote: I thought it would be good to raise a structural question here rather than in the commons-complex JIRA. The Complex library has multiple dependencies on three packages: -- commons-math base classes (e.g. Field et al.) Do

Re: [complex][math-util] dependencies

Hi Eric, Eric Barnhill wrote: > I thought it would be good to raise a structural question here rather than > in the commons-complex JIRA. > > The Complex library has multiple dependencies on three packages: > > -- commons-math base classes (e.g. Field et al.) > -- commons-math exceptions > --

[complex][math-util] dependencies

I thought it would be good to raise a structural question here rather than in the commons-complex JIRA. The Complex library has multiple dependencies on three packages: -- commons-math base classes (e.g. Field et al.) -- commons-math exceptions -- commons-math util (numerous classes) Otherwise

Re: [Filter] Better name? (Was: [math] IIR filter library [...])

Changed sandbox folder name to "sigproc". Eric On Fri, Nov 25, 2016 at 9:01 PM, Gary Gregory wrote: > On Thu, Nov 24, 2016 at 12:20 AM, Bernd Porr wrote: > > > Hi Gilles, > > > > I like the idea of "SigProc". Filter is a bit too narrow especially

[GitHub] commons-fileupload issue #5: Update DiskFileItem.java: Avoiding NPE when not...

Github user OleHornischer commented on the issue: https://github.com/apache/commons-fileupload/pull/5 Thanks for the tip. I updated my repository in accordance to the script on the linked blog post. Hope things are in order now. --- If your project is set up for it, you can