Re: [lang] Thread safety annotations

Ah, ok, what I have in there now is in our own package. Gary On Nov 27, 2016 8:06 PM, "Matt Sicker" wrote: > Well, HttpClient used to have the same (or similar) thread safety > annotations for documentation purposes, and I think they were just custom > annotations and not the

Re: [lang] Thread safety annotations

Well, HttpClient used to have the same (or similar) thread safety annotations for documentation purposes, and I think they were just custom annotations and not the javax ones. On 27 November 2016 at 20:50, Gary Gregory wrote: > On Nov 27, 2016 6:46 PM, "Matt Sicker"

Re: [lang] Thread safety annotations

On Nov 27, 2016 6:46 PM, "Matt Sicker" wrote: > > I'd be in favor of just including this as an internal annotation similar to > how it's done in HttpClient. What does that mean specifically? FWIW, I think those annotations might be gone in the current svn trunk. Gary > > On 27

Re: [lang] Thread safety annotations

Oh, and JSR 305 does not actually specify any concurrency annotations. Gary On Nov 27, 2016 6:46 PM, "Matt Sicker" wrote: > I'd be in favor of just including this as an internal annotation similar to > how it's done in HttpClient. > > On 27 November 2016 at 20:44, Gary

Re: [lang] Thread safety annotations

Also note that the JCIP code uses its own package AND declares the annotations with the RUNTIME retention policy. Gary On Nov 27, 2016 6:39 PM, "Matt Sicker" wrote: > If you're going to share the annotations between projects, why not use a > JSR package for it like the google

Re: [lang] Thread safety annotations

I'd be in favor of just including this as an internal annotation similar to how it's done in HttpClient. On 27 November 2016 at 20:44, Gary Gregory wrote: > I do not think we should use an official Java package because the JSR 305 > page says "The Executive Committee

Re: [lang] Thread safety annotations

I do not think we should use an official Java package because the JSR 305 page says "The Executive Committee voted to list this JSR as dormant in May 2012." Gary On Nov 27, 2016 6:39 PM, "Matt Sicker" wrote: > If you're going to share the annotations between projects, why not

Re: [lang] Thread safety annotations

If you're going to share the annotations between projects, why not use a JSR package for it like the google one? I thought the idea of embedding the annotations in [lang] was to prevent the need for the dependency and to use it internally, not as a public annotation for other projects to use. On

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

Here's an example of a confusing versioning situation: 1. commons-foo-base version 1.1 is released 2. commons-foo-utils is still at version 1.0 as no code was updated. Do you release a 1.0.1 with a dependency update on commons-foo-base 1.1, or do you go with version 1.1 to match, or do you not

Re: [lang] Thread safety annotations

Are you suggesting [lang] becomes a multi-module project? Gary On Nov 27, 2016 5:01 PM, "sebb" wrote: > On 28 November 2016 at 00:11, Gary Gregory wrote: > > On Sun, Nov 27, 2016 at 4:09 PM, sebb wrote: > > > >> On 27 November 2016

Re: [lang] Thread safety annotations

On 28 November 2016 at 00:11, Gary Gregory wrote: > On Sun, Nov 27, 2016 at 4:09 PM, sebb wrote: > >> On 27 November 2016 at 23:51, Gary Gregory wrote: >> > On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote: >> > >>

Re: [lang] Thread safety annotations

On 28 November 2016 at 10:51, Gary Gregory wrote: > On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote: > >> On 27 November 2016 at 22:31, Gary Gregory wrote: >> > On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote: >> > >>

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

[...] Let's keep in mind the context here: This is a component in Apache Commons, not a TLP. Therefore, IMO, we should match user's expectations of simplicity, which is one repo and version for the component, multi-module or not, just like all of the other Apache Commons components, where

Re: [lang] Thread safety annotations

On Sun, Nov 27, 2016 at 4:09 PM, sebb wrote: > On 27 November 2016 at 23:51, Gary Gregory wrote: > > On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote: > > > >> On 27 November 2016 at 22:31, Gary Gregory > wrote: >

Re: [lang] Thread safety annotations

On 27 November 2016 at 23:51, Gary Gregory wrote: > On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote: > >> On 27 November 2016 at 22:31, Gary Gregory wrote: >> > On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote: >> > >>

Re: [lang] Thread safety annotations

On Sun, Nov 27, 2016 at 3:51 PM, Gary Gregory wrote: > On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote: > >> On 27 November 2016 at 22:31, Gary Gregory >> wrote: >> > On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote:

Re: [lang] Thread safety annotations

On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote: > On 27 November 2016 at 22:31, Gary Gregory wrote: > > On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote: > > > >> On 27 November 2016 at 22:03, Gary Gregory > wrote: >

Re: [lang] Thread safety annotations

On 28 November 2016 at 10:41, sebb wrote: > On 27 November 2016 at 22:31, Gary Gregory wrote: >> It is _because_ they are NOT built-in the language or JRE that we are >> proposing they belong in [lang]. >> >> Since we are providing the annotation with

Re: [lang] Thread safety annotations

Please see https://issues.apache.org/jira/browse/LANG-1291 and git master main and unit tests. It's pretty neat that you can only have a compile-time dependency and not a runtime dependency as the unit tests show. Gary On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote: > On 27

Re: [lang] Thread safety annotations

On 27 November 2016 at 22:31, Gary Gregory wrote: > On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote: > >> On 27 November 2016 at 22:03, Gary Gregory wrote: >> > These annotations are the SAME as have been published all over the

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

On Sun, 27 Nov 2016 21:19:16 +, Benedikt Ritter wrote: [...] You have asked for opinions - be prepared people don't agree with you. [...] Just because it is supported doesn't mean it is a good idea. I actually expected arguments as to why it would not be a good idea. You are

Re: [lang] Thread safety annotations

On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote: > On 27 November 2016 at 22:03, Gary Gregory wrote: > > These annotations are the SAME as have been published all over the place, > > so I do not think we need a PR for review. Reviewing the code in the repo

Re: [lang] Thread safety annotations

On 27 November 2016 at 22:03, Gary Gregory wrote: > These annotations are the SAME as have been published all over the place, > so I do not think we need a PR for review. Reviewing the code in the repo > should be enough, but I'm not sure _what_ there is to review really.

Re: [Codec] base 122?

An email is going to be lost. Why not create a JIRA enhancement? On 27 November 2016 at 20:07, Gary Gregory wrote: > Bookmarking for consideration: http://blog.kevinalbs.com/base122 > > Gary - To

Re: [lang] Thread safety annotations

These annotations are the SAME as have been published all over the place, so I do not think we need a PR for review. Reviewing the code in the repo should be enough, but I'm not sure _what_ there is to review really. I've already posted a link to the sources (a pastebin link). I'll create a Jira

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

On Sun, Nov 27, 2016 at 1:19 PM, Benedikt Ritter wrote: > Hello Gilles, > > Gilles schrieb am So., 27. Nov. 2016 um > 22:11 Uhr: > > > On Sun, 27 Nov 2016 11:52:12 -0600, Matt Sicker wrote: > > > I think everything would be much easier to just

Re: [lang] Thread safety annotations

Hi, Gary Gregory schrieb am So., 27. Nov. 2016 um 21:01 Uhr: > So let's start with the CLASS retention annotations first. I'll commit > later today. > Maybe create a GitHub PR so people can have a look before it goes to master? Benedikt > > Gary > > On Nov 27, 2016

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

Hello Gilles, Gilles schrieb am So., 27. Nov. 2016 um 22:11 Uhr: > On Sun, 27 Nov 2016 11:52:12 -0600, Matt Sicker wrote: > > I think everything would be much easier to just maintain one version > > per > > repository. Besides, it would get confusing having

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

On Sun, 27 Nov 2016 11:52:12 -0600, Matt Sicker wrote: I think everything would be much easier to just maintain one version per repository. Besides, it would get confusing having multiple git tags or svn tags for different component versions, especially if a repository uses short tag names

[Codec] base 122?

Bookmarking for consideration: http://blog.kevinalbs.com/base122 Gary

Re: [lang] Thread safety annotations

So let's start with the CLASS retention annotations first. I'll commit later today. Gary On Nov 27, 2016 9:50 AM, "Matt Sicker" wrote: > I feel like documenting thread safety in such a low level, widely used > library like [lang] is a great idea. Whether it uses annotations,

Re: [lang] Thread safety annotations

My view is that it might be challenging to do and keep the information accurate over time, but that this is a worthy goal nonetheless. Having the annotations around will allow for anyone to do this in a standard way. Coming up with a Javadoc only way to do this is too much of a pain IMO. Gary On

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

I think everything would be much easier to just maintain one version per repository. Besides, it would get confusing having multiple git tags or svn tags for different component versions, especially if a repository uses short tag names that only include the version number and not the component

Re: [lang] Thread safety annotations

I feel like documenting thread safety in such a low level, widely used library like [lang] is a great idea. Whether it uses annotations, javadocs, or some sort of informal javadoc comments isn't too big a deal to me, but providing some guarantees of thread safety or lack thereof would be

Re: commons-compress git commit: upgrade XZ for Java dependency

Would you mind creating a Jira for this and updating changes.xml? Gary On Nov 27, 2016 8:11 AM, wrote: > Repository: commons-compress > Updated Branches: > refs/heads/master c1e73721b -> 1a31dec12 > > > upgrade XZ for Java dependency > > > Project:

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

I forgot to mention that it seems to me that this (a singly versions block of code) is the fundamental "meaning" of what a repository is. I mean that in the sense that if you want separate separately versioned components, that is a direct argument for separate repositories. With that said,

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

I'm also in the "one-version per repository"-camp. Benedikt Stian Soiland-Reyes schrieb am So., 27. Nov. 2016 um 11:48 Uhr: > I think Gilles' reasoning is sound for semantic versioning and releases, in > line with OSGi principles. However I think that would be better suited

Re: [lang] Thread safety annotations

I thought we decided to abstain from documenting thread safety since it would get outdated quickly anyway. Gary Gregory schrieb am So., 27. Nov. 2016 um 09:11 Uhr: > But if we then want a runtime version we had an odd packaging with CLASS > retention in .concurrent. and

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

I think Gilles' reasoning is sound for semantic versioning and releases, in line with OSGi principles. However I think that would be better suited in a large or enterprise project with mainly internal usersnpf the libraries that can play along, not in Apache Commons which are making general

[VOTE][LAZY] Release Commons Parent POM 42 based on RC1

We have added some enhancements since Commons Parent POM 41 was released, so I would like to release Commons Parent POM 42. Commons Parent POM 42 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/commons-parent/42-RC1/ (svn revision 17171) The tag is here:

Re: [lang] Thread safety annotations

But if we then want a runtime version we had an odd packaging with CLASS retention in .concurrent. and RUNTIME in .concurrent.runtime. I might be in YAGNI territory here... Gary On Sat, Nov 26, 2016 at 10:07 PM, Matt Sicker wrote: > I think adding the additional