Re: Modular version/edition of Apache Commons

[ajs6f]

Since each Commons component is released separately, each can have its own
plan.

ajs6f


> On Fri, Nov 30, 2018, 8:46 AM Hannes H. 
>> Hi,
>>
>> I am talking about Apache Commons in general and its approach to Java
>> modules which came with JDK 9 (project Jigsaw).
>>
>> Hannes
>>
>> Am Fr., 30. Nov. 2018 um 13:22 Uhr schrieb Gary Gregory <
>> garydgreg...@gmail.com>:
>>
>> > Hi,
>> >
>> > Apache Common is a single project but is made up of Components that are
>> > developed and released individually.
>> >
>> > Can you be more specific? Which Components are you talking about?
>> >
>> > Gary
>> >
>> > On Fri, Nov 30, 2018, 01:52 Hannes H. > >
>> > > Good day,
>> > >
>> > > while migrating a code base which depends on Apache Commons from Java
>> 8
>> > to
>> > > Java 11 the problem with 'split packages' crossed my efforts to do so.
>> > >
>> > > I did some research but I could not find anything, so I try by asking
>> > here:
>> > > Is there a modularized version/edition of Apache Commons available,
>> or is
>> > > there a timeline until when this will be done?
>> > >
>> > > If not: Is there any suggestion on how to approach that problem when
>> > > migration to a newer, jigsaw-enabled JDK version?
>> > >
>> > > Thanks for your time and help,
>> > > Hannes
>> > >
>> >
>>
>

Re: [Lang] CheckedFunction#unchecked

[ajs6f]

Please do! This is a pretty common need and it would be nice to present a 
really well-designed set of types for it.

ajs6f

> On Nov 29, 2018, at 2:41 PM, Aleksander Ściborek 
>  wrote:
> 
> Ok, so I'm going to continue snd  in the near future I will create pull
> request with a lot of checked functions like Consumer, Predicate
> BinaryFuncton etc.
> 
> On Sat, Nov 24, 2018, 15:01 ajs6f  
>> In that case you might want to also look at some other choices people have
>> made like
>> 
>> https://github.com/google/mug#maybe
>> 
>> or even more specialized facilities like
>> 
>> https://github.com/google/chkstream
>> 
>> I'm not against plain general functional types that handle checked
>> exceptions (I imagine most of us have written them for ourselves at some
>> point, which makes them a good candidate for Commons), but I've found that
>> generally I end up with clearer code if I can use an idiom more specific to
>> the task.
>> 
>> ajs6f
>> 
>>> On Nov 24, 2018, at 8:46 AM, Aleksander Ściborek <
>> aleksanderscibo...@gmail.com> wrote:
>>> 
>>> Of course you are right. I'm going to add new functions. The idea behind
>>> this pull request is to show what I want to create, that's why I marked
>> PR
>>> as WIP (Work in Progress)
>>> 
>>> On Sat, Nov 24, 2018, 14:31 ajs6f >> 
>>>> I would rather see a more complete offering with the other types in
>>>> j.u.function, i.e. Consumer, Supplier, Predicate, the various
>>>> primitive-specialized types...
>>>> 
>>>> ajs6f
>>>> 
>>>>> On Nov 24, 2018, at 6:58 AM, Pascal Schumacher <
>> pascalschumac...@gmx.net>
>>>> wrote:
>>>>> 
>>>>> Hi Aleksander,
>>>>> 
>>>>> thanks.
>>>>> 
>>>>> Imho this would be a useful addition to commons-lang.
>>>>> 
>>>>> Any other opinions?
>>>>> 
>>>>> Cheers,
>>>>> Pascal
>>>>> 
>>>>> Am 21.11.2018 um 22:52 schrieb Aleksander Ściborek:
>>>>>> Hi
>>>>>> I've just created pull request
>>>>>> <https://github.com/apache/commons-lang/pull/385> for
>> CheeckedFunction
>>>>>> interface. This is an example of utils I would like to add in order to
>>>>>> simplify usage of java Stream.
>>>>>> Aleksander
>>>>>> 
>>>>> 
>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>> 
>>>> 
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>> 
>>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 


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

Re: [Lang] CheckedFunction#unchecked

[ajs6f]

In that case you might want to also look at some other choices people have made 
like

https://github.com/google/mug#maybe

or even more specialized facilities like

https://github.com/google/chkstream

I'm not against plain general functional types that handle checked exceptions 
(I imagine most of us have written them for ourselves at some point, which 
makes them a good candidate for Commons), but I've found that generally I end 
up with clearer code if I can use an idiom more specific to the task.

ajs6f

> On Nov 24, 2018, at 8:46 AM, Aleksander Ściborek 
>  wrote:
> 
> Of course you are right. I'm going to add new functions. The idea behind
> this pull request is to show what I want to create, that's why I marked PR
> as WIP (Work in Progress)
> 
> On Sat, Nov 24, 2018, 14:31 ajs6f  
>> I would rather see a more complete offering with the other types in
>> j.u.function, i.e. Consumer, Supplier, Predicate, the various
>> primitive-specialized types...
>> 
>> ajs6f
>> 
>>> On Nov 24, 2018, at 6:58 AM, Pascal Schumacher 
>> wrote:
>>> 
>>> Hi Aleksander,
>>> 
>>> thanks.
>>> 
>>> Imho this would be a useful addition to commons-lang.
>>> 
>>> Any other opinions?
>>> 
>>> Cheers,
>>> Pascal
>>> 
>>> Am 21.11.2018 um 22:52 schrieb Aleksander Ściborek:
>>>> Hi
>>>> I've just created pull request
>>>> <https://github.com/apache/commons-lang/pull/385> for CheeckedFunction
>>>> interface. This is an example of utils I would like to add in order to
>>>> simplify usage of java Stream.
>>>> Aleksander
>>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 


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

Re: [Lang] CheckedFunction#unchecked

[ajs6f]

I would rather see a more complete offering with the other types in 
j.u.function, i.e. Consumer, Supplier, Predicate, the various 
primitive-specialized types...

ajs6f

> On Nov 24, 2018, at 6:58 AM, Pascal Schumacher  
> wrote:
> 
> Hi Aleksander,
> 
> thanks.
> 
> Imho this would be a useful addition to commons-lang.
> 
> Any other opinions?
> 
> Cheers,
> Pascal
> 
> Am 21.11.2018 um 22:52 schrieb Aleksander Ściborek:
>> Hi
>> I've just created pull request
>> <https://github.com/apache/commons-lang/pull/385> for CheeckedFunction
>> interface. This is an example of utils I would like to add in order to
>> simplify usage of java Stream.
>> Aleksander
>> 
> 
> 
> -
> 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: [draft] Board report for September 2018

[ajs6f]

> On Sep 12, 2018, at 8:00 PM, Gilles  wrote:
> 
>> Incomplete stats from https://demo.kibble.apache.org:
>> - 977 Authors this period; Down -4% since last period
>> - 19,242 Commits this periodl; Down -21% since last period
>> - 558 Committers this period; Down -3% since last period
>> - 10,881,243 Lines changed this period; Down -19% since last period
> 
> More realistic would be
> * 40 authors (-11%)
> * 659 commits (-18%)
> * 32 committers (+33%)
> * 53,659 lines changed (-23%)
> 
> 
> Gilles

"10,881,243 Lines changed this period" does seem a bit surprising, but I did 
not notice it at all before Gilles' remark.

ajs6f


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

Re: [all] - git: prevent unnecessary merge commits?

[ajs6f]

+1. Unless there is a specific reason to incur a merge commit, it's generally 
noise.

ajs6f

> On Jun 9, 2018, at 5:03 AM, Bruno P. Kinoshita 
>  wrote:
> 
> Hi Pascal,
> 
> Apache OpenNLP uses that approach whenever possible 
> (http://opennlp.apache.org/using-git.html). I like the way the commit tree 
> looks after a while. Sometimes it's not practical, especially when receiving 
> patches from external contributors (developers can still check-out code 
> locally and squash commits & rebase, but sometimes it can get messy and take 
> much longer).
> 
> I'm +1 for recommending this as a good practice. In my workflow I normally 
> `fetch` + `rebase`, instead of `pull`.
> 
> Cheers,
> Bruno
> 
> 
> 
> 
> 
> From: Pascal Schumacher 
> To: Commons Developers List  
> Sent: Saturday, 9 June 2018 8:53 PM
> Subject: [all] - git: prevent unnecessary merge commits?
> 
> 
> 
> Hello everybody,
> 
> 
> in my opinion it is a good practice to always use the "--rebase" option 
> 
> when using "git pull". This keeps the history free of unnecessary merge 
> 
> commits like "Merge branch 'master' of 
> 
> https://git-wip-us.apache.org/repo...;.
> 
> 
> You can also tell git to automatically rebase when pulling:
> 
> 
> git config --global pull.rebase true
> 
> 
> What do you think?
> 
> 
> Cheers,
> 
> 
> Pascal
> 
> 
> 
> -
> 
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> 
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: [ALL] SHA-1 vs. SHA-256

[ajs6f]

> On May 19, 2018, at 5:34 AM, Emmanuel Bourg <ebo...@apache.org> wrote:
> On 18/05/2018 17:30, Gary Gregory wrote:
> 
>> Thoughts?
> 
> I wouldn't bother. The checksum is just there to ensure the download worked 
> properly, and for this even md5 is fine.
> 
> The authenticity of the artifacts is ensured by the GPG signatures.
> 
> Emmanuel Bourg

True, but there's a considerable portion of users who check the checksums and 
nothing else. 

ajs6f


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

Re: [ALL] SHA-1 vs. SHA-256

[ajs6f]

+1

ajs6f

> On May 18, 2018, at 5:50 PM, Bruno P. Kinoshita <ki...@apache.org> wrote:
> 
> No objections from me. +1
> 
> Sent from Yahoo Mail on Android 
> 
>  On Sat, 19 May 2018 at 9:24, Gary Gregory<garydgreg...@gmail.com> wrote:   
> Hi All:
> 
> Eclipse is moving to SHA-256 to validate downloads [1] alongside MD5.
> 
> We just updated to SHA-1 which apparently has been subject to a collision
> attack [2].
> 
> Our newish commons-release-plugin has just been updated to SHA-1.
> 
> I'd like to add SHA-256 alongside SHA-1.
> 
> Thoughts?
> 
> [1]
> https://www.eclipse.org/eclipse/news/4.8/platform_isv.php#equinox-sha-256-checksum
> [2]
> https://arstechnica.com/information-technology/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/
> 


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

Re: [VOTE] Migrate existing Git repos to GitBox

[ajs6f]

I have asked INFRA about this (for another project) and they confirmed that 
GitBox runs the mirroring Github => Apache, so that PRs can be merged at 
Github. I did not ask about whether commits can also be pushed directly to 
Apache.

ajs6f

> On Apr 22, 2018, at 3:03 PM, Matt Sicker <boa...@gmail.com> wrote:
> 
> On 22 April 2018 at 13:34, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
>> For example, with GitBox can we now merge pull requests directly at
>> GitHub? That would be a nice benefit.  Can we still commit to the ASF git
>> repo or only at GitHub?
>> 
> 
> From my understanding, you can merge PRs directly via the UI (or the "hub"
> command line tool). As for where you push code, it seems to be driven from
> either repository (apache or github), though that might be configurable to
> avoid history conflicts.
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com>


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

Re: [httpclient] Better user agent header?

[ajs6f]

For at least some cases, this wouldn't be good for security. I would prefer 
that this be configurable (via HttpClientBuilder and/or system props) and not 
the default.

ajs6f

> On Mar 29, 2018, at 6:20 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> Hi All:
> 
> Right now, the HttpClient is of the form:
> 
> User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_162)
> 
> With the stack I am working with, it would be handy if the header reflected:
> 
> - The Java vendor
> - Operating system name and version.
> 
> For example:
> 
> User-Agent: Apache-HttpClient/4.5.5 (Oracle Corporation/Java/1.8.0_162)
> Windows/10.0 (amd64)
> 
> Any thoughts for or against adding this to the user agent string?
> 
> Gary


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

Re: Github usage

[ajs6f]

One gotcha that has bit me before-- if the PR isn't rebased over the current 
master (assuming you are merging into master) it may still be merge-able 
because maybe there aren't any conflicts. (E.g. maybe no one has worked on that 
section of the codebase since the PR's branch was branched.)

But if you merge without rebasing, Apache's mirroring won't realize that the PR 
should be closed (as I understand it, because the commits will have different 
hashes since they are diffs between different places on the tree). So best to 
rebase if needed, but you forget and this happens to you, you can still rebase 
and force-push the PR branch, and then Apache's mirroring will catch up and 
close the PR "posthumously". Or of course you can always close it manually on 
Github.

I make this mistake about once a month or so. :(

ajs6f

> On Mar 14, 2018, at 12:27 PM, Matt Sicker <boa...@gmail.com> wrote:
> 
> When you have a GitHub origin, you can checkout pulls/42/head to check out
> PR#42. You can pull/merge from that branch as well to merge the PR (by
> committing and pushing that merge, GitHub will notice and mark the PR as
> merged). You can also use the "hub" command line tool that GitHub publishes
> which adds a bunch of convenience commands to do the same thing.
> 
> On 14 March 2018 at 10:19, Gilles <gil...@harfang.homelinux.org> wrote:
> 
>> Hi.
>> 
>> On Wed, 14 Mar 2018 14:16:42 +, Otto Fowler wrote:
>> 
>>> I should be more specific, this is for looking at github pr’s.
>>> So if your submitters are forking, submitting prs on github.
>>> 
>>> We also have scripts for committing, but we are doing git -> github mirror
>>> 
>> 
>> My knowledge of "git" is small; my knowledge of GitHub smaller
>> (and zero for functionalities that require being logged in). :-}
>> 
>> Assuming a "git" repository (where "origin" is on an Apache server)
>> with a local "clone" (i.e. on my machine), is it possible to create
>> a branch, say "gimo_work", such that
>> 
>> $ git checkout gimo_work
>> $ git ... ? ... (equivalent to "pull" wrt "origin")
>> 
>> will retrieve the latest Gimo's commits on the fork made
>> from the Apache repository?
>> 
>> Gilles
>> 
>> On March 14, 2018 at 10:15:04, Otto Fowler (ottobackwa...@gmail.com)
>>> wrote:
>>> 
>>> We have script to help reviewers checkout PR’s in git, either in their own
>>> repo
>>> or just doing it in ~/tmp or something into a new repo.
>>> 
>>> So, I would run:
>>> 
>>> checkout-pr 999
>>>> 
>>> 
>>> in the tmp directory, and end up with a local version that I can then
>>> build
>>> and do whatever with.
>>> would that help?
>>> 
>>> 
>>> On March 14, 2018 at 10:08:47, Gilles (gil...@harfang.homelinux.org)
>>> wrote:
>>> 
>>> On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:
>>> 
>>>> On Mar 13, 2018, at 11:20 AM, Gilles <gil...@harfang.homelinux.org>
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> I didn't find it very easy to cooperate with developers who fork on
>>>>> GitHub and submit PRs. I've now found the "git" command that creates a
>>>>> branch from a PR, but it would be so much more comfortable to just
>>>>> switch directory and do "git pull".
>>>>> 
>>>>> 
>>>> Just as a point of information, it is possible to reverse the Github
>>>> <- Apache mirroring most projects use to be Github -> Apache.
>>>> 
>>> 
>>> It seems that a good-enough-for-me solution would be to "clone"
>>> (on my local system) the repository forked by the GSoC participant.
>>> 
>>> Does it make sense?
>>> 
>>> Thanks,
>>> Gilles
>>> 
>>> What
>>>> that means is that merging PRs from Github becomes one click in the
>>>> Github UI.
>>>> 
>>>> There are other consequences, of course, especially related to other
>>>> integrations Commons may be using (e.g. integration between Github
>>>> and
>>>> JIRA).
>>>> 
>>>> Of course, INFRA are the folks to talk to if this sounds interesting.
>>>> At Apache Jena, we looked into it but have taken no action because we
>>>> still have some open questions about when some of our workflow
>>>> integrations will become possible with "reversed mirroring".
>>>> 
>>>> Adam Soroka ; aj...@apache.org
>>>> 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com>


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

Github usage Was: [Statistics] Port codes from Commons Math

[ajs6f]

> On Mar 13, 2018, at 11:20 AM, Gilles  wrote:
> 
> 
> I didn't find it very easy to cooperate with developers who fork on GitHub 
> and submit PRs. I've now found the "git" command that creates a branch from a 
> PR, but it would be so much more comfortable to just switch directory and do 
> "git pull".
> 

Just as a point of information, it is possible to reverse the Github <- Apache 
mirroring most projects use to be Github -> Apache. What that means is that 
merging PRs from Github becomes one click in the Github UI. 

There are other consequences, of course, especially related to other 
integrations Commons may be using (e.g. integration between Github and JIRA).

Of course, INFRA are the folks to talk to if this sounds interesting. At Apache 
Jena, we looked into it but have taken no action because we still have some 
open questions about when some of our workflow integrations will become 
possible with "reversed mirroring".

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

Re: Prepare commons to JDK 9

[ajs6f]

> On Mar 12, 2018, at 1:13 PM, Ralph Goers  wrote:
> 
> 
> 
>> On Mar 12, 2018, at 9:27 AM, Jörg Schaible  wrote:
>> 
>> Hi Ralph,
>> 
>> On Wed, 07 Mar 2018 11:56:32 -0700 Ralph Goers wrote:
>>> 
>>> Actually, you really do need to use a multi-release jar to include a 
>>> module-info class file. Otherwise it may be sitting alongside of classes 
>>> compiled for an earlier java release and various tools will fail becaus of 
>>> it.
>> 
>> Not necessarily. XStream contains for more than a decade class files 
>> targeting different Java versions. Works  normally fine as long as nobody 
>> tries to load a class that cannot handled by the current runtime. Android 
>> has its problems with it, but it has already problems with Java 8 ;-)
> 
> You statement just proved my point. “Works fine as long as …”.  So as soon as 
> you want to support those various tools you have to stop doing that.
> 
> Ralph

Is there actually a standard list of tools or other build apparatus that is to 
be supported by Commons releases? I can name lots and lots of tools that won't 
work with Java 7 or even earlier versions. Most of them don't matter at all. 
I'm not making a claim about any particular tool or toolchain (including 
Android), but a general point.

I'd like to understand when "if we try X, our artifacts won't work on Y" is a 
valid blocker for a Commons project. In this case, the project (as has been 
repeatedly explained) aims to do nothing more than understand the conditions 
for using X and how to meet them, so I don't see how Android's (or any other 
specific project's) problems are a blocker at all. If anything, concern with 
problems for Android usage should be assuaged by a project that will help turn 
up more data about those problems.

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

Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

[ajs6f]

> On Mar 8, 2018, at 12:48 PM, Gary Gregory  wrote:
> On Thu, Mar 8, 2018 at 10:29 AM, Gilles 
> wrote:
>> Then these modules can define "module-info" files, and an actual build will 
>> prove that the dependencies are as expected.
>> 
> As Ralph as pointed out, you cannot generate a module-info file without also 
> using an MR Jar unless you also want to make Java 9 your base line.

I'm not sure whether we would want to do this in a Maven profile (certainly the 
other way can work) but if not, we can use a Git branch for the purpose. In any 
event, there is a difference between working with Java 9 for a GSoC project and 
moving the component to Java 9. 

Again, just to clarify, in no way does this project propose to move the normal 
(release) baseline for anything at all. (As a side note, I would like to be the 
first to argue against _ever_ moving it to the non-LTS Java 9, but I think I 
will have to get in a long line of people who would argue against that! :) )

Adam Soroka ; aj...@apache.org


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

Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

[ajs6f]

> On Mar 8, 2018, at 8:33 AM, Gilles  wrote:
> Would it be useful (and interesting as part of GSoC work) to
> establish
> (1) which tools requires fixing,
> (2) prepare enhancement requests for the respective projects,
> and in the meantime, adapt the "Commons" build (with a "JDK 9"
> profile)
> (3) to disable plugins that do not work yet,
> (4) provide the option to generate a "multi-release" JAR (although
>it would not be the deployed as part of the official release
>process)?

Hi, this is Adam Soroka (prospective mentor for this project). I'm sorry to 
have been absent from this conversation so far (been very busy this week) but 
Gilles has said much of what I would have said, so thanks Gilles!

I would emphasize a couple of points:

This is a GSoC project. The expectations and the marks of success are 
fundamentally different than for many other contributions. 

Gilles has rightly pointed out that this is about Commons RDF and that is all. 
Kamila unfortunately didn't make that clear in the subject line of the thread, 
but that was just a slip of the keyboard. It's not about any other piece of 
Commons. It won't affect them, so there's no need to worry about how release 
artifacts or other products for other components might be affected. They won't 
be.

I don't think anyone would claim (or has claimed) that Commons (or any Commons 
component) should target Java9. The idea here is to work with the JPMS. There 
is no obvious or sensible way to do that without using Java9.

The tasks that Kamila and Gilles have talked about are (IMHO) sensible and 
useful. We can discuss how soon and in what way Commons as a whole should 
engage with JPMS, but I don't see why that should stop individual components 
from exploring it. In fact, as Gilles points out, that will be a useful way of 
gathering info for a larger set of efforts.

Lastly, on the assumption that Kamila's work involves a lot of "well, plugin X 
doesn't work, so I'll have to talk to that project", we are doing good. That is 
_EXACTLY_ what should happen during a GSoC project. The student should be 
discovering that working on open source software is often (I would say _very_ 
often) just as much about understanding how different software projects and 
communities relate to each other and how to get efforts synchronized than about 
just banging out line after line of code in isolation, only to throw the 
results over a fence to a single project.

In summary-- this proposed project shouldn't affect anything or -one outside of 
the user base of Commons RDF (which hasn't even reached 1.0), and it may only 
result in a lot of documentation and "speculative" work, and that would be 
fine, as long as Kamila learns a lot about working with open source software 
efforts, which I'm confident she can and will.

Adam Soroka ; aj...@apache.org





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

Re: [text] Upper/Lower case enum

[ajs6f]

Perhaps ?

ajs6f

> On Feb 23, 2018, at 12:12 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> On Fri, Feb 23, 2018 at 10:05 AM, Gary Gregory <garydgreg...@gmail.com>
> wrote:
> 
>> 
>> 
>> On Fri, Feb 23, 2018 at 10:04 AM, Gary Gregory <garydgreg...@gmail.com>
>> wrote:
>> 
>>> 
>>> 
>>> On Fri, Feb 23, 2018 at 7:03 AM, Matt Benson <mben...@apache.org> wrote:
>>> 
>>>> On Feb 23, 2018 4:26 AM, "sebb" <seb...@gmail.com> wrote:
>>>> 
>>>> On 23 February 2018 at 00:41, Gary Gregory <garydgreg...@gmail.com>
>>>> wrote:
>>>>> On Thu, Feb 22, 2018 at 4:27 PM, sebb <seb...@gmail.com> wrote:
>>>>> 
>>>>>> On 22 February 2018 at 23:15, Gary Gregory <garydgreg...@gmail.com>
>>>> wrote:
>>>>>>> On Thu, Feb 22, 2018 at 4:11 PM, sebb <seb...@gmail.com> wrote:
>>>>>>> 
>>>>>>>> On 22 February 2018 at 22:27, Gary Gregory <garydgreg...@gmail.com
>>>>> 
>>>>>> wrote:
>>>>>>>>> Use your imagination ;-)
>>>>>>>> 
>>>>>>>> What would the new code look like?
>>>>>> 
>>>>>> I mean the user code before and after the enum is introduced.
>>>>>> 
>>>>> 
>>>>> I don't have code for the _before_ since I wrote the enum to avoid it.
>>>>> 
>>>>> I have a different util class that gets called like this:
>>>>> 
>>>>> HexDump(byte[] data, LetterCase letterCase, more details...)
>>>> 
>>>> The above is only using the enum as a way to provide the requested
>>>> type of transform.
>>>> 
>>>> The important bit is the code that uses the enum to do the transform.
>>>> 
>>>> 
>>>> Obviously the method body would call #toCaseString() passing a String and
>>>> Locale as arguments. This question feels like trolling, as does the
>>>> insinuation that true/false *might not* be less clear in intent than
>>>> UPPER/LOWER, or vice versa as, again, we don't know what the hypothetical
>>>> API author was thinking in the case of boolean. WTH
>>>> 
>>> 
>>> Thanks Matt for pointing that out. The comment did feel trollish to me as
>>> well but I choose not to engage. Aside from that I really like Sebb's
>>> contributions to our community, his diligence and attention to detail.
>>> I did not think I needed to make some pedantic point about an enum being
>>> much better than a boolean to express letter case or toggles in general.
>>> 
>>> 
>>>> The comment about Java 8 is fine as far as it goes, but doesn't really
>>>> invalidate this as the method supplied can easily be used as a
>>>> BiFunction.
>>>> Gary, I'm thinking you might as well "underload" the method to pass the
>>>> default Locale to the two-argument variant so then you also implement
>>>> Function in the simple case. Then I'm sold. For a bonus you might provide
>>>> char method variants as well.
>>>> 
>>> 
>>> OK, sounds good. Like this then:
>>> [https://pastebin.com/mJw2tDHj]
>>> 
>> 
>> Without the @author tag of course.
>> 
> 
> There is also CharBuffer... I only have use for String.
> 
> Gary
> 
> 
>> 
>> G
>> 
>>> 
>>> import java.util.Locale;
>>> 
>>> /**
>>> * Enumerates letter cases and converts strings.
>>> *
>>> * @author mailto:ggreg...@rocketsoftware.com;>Gary Gregory
>>> */
>>> public enum LetterCase {
>>> 
>>>LOWER {
>>>@Override
>>>public char[] toCaseString(final char[] source, final Locale
>>> locale) {
>>>return String.valueOf(source).toLower
>>> Case(locale).toCharArray();
>>>}
>>> 
>>>@Override
>>>public String toCaseString(final String source, final Locale
>>> locale) {
>>>return source.toLowerCase(locale);
>>>}
>>> 
>>>},
>>>UPPER {
>>>@Override
>>>public char[] toCaseString(final char[] source, final Locale
>>> locale) {
>>>return String.valueOf(source).toUpper
>>> Case(locale).toCharArra

[GitHub] commons-rdf pull request #49: Cleanup for FindBugs and PMD warnings in -simp...

[ajs6f]

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/commons-rdf/pull/49#discussion_r168275645
  
--- Diff: 
commons-rdf-simple/src/main/java/org/apache/commons/rdf/simple/experimental/AbstractRDFParser.java
 ---
@@ -58,8 +60,12 @@
  */
 public abstract class AbstractRDFParser> 
implements RDFParser, Cloneable {
 
-public static final ThreadGroup threadGroup = new ThreadGroup("Commons 
RDF parsers");
-private static final ExecutorService threadpool = 
Executors.newCachedThreadPool(r -> new Thread(threadGroup, r));
+public static final AtomicInteger threadCount = new AtomicInteger();
+private static Thread newThread(Runnable r) {
--- End diff --

That's why I put [the name "Commons RDF Parser 
"](https://github.com/apache/commons-rdf/pull/49/files/f1649e034a2623137434fcc2810f8802d3ee9434#diff-68c2acaf43f1ae22da0bdb4eac55a201R65)
 back in. But like I said, I am fine with whatever- I was just tearing through 
PMD warnings at speed after the comment (I think to the board report) about 
there being a lot of them. Shall I take your comment as a direction to remove 
this change? Happy to...


---

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

[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
Okay, I'll get to work on factoring out a (serializable) factory. Thanks 
for the discussion everyone! I think the parser types will be much stronger for 
it.


---

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

[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
Hm... if @afs and @stain are both feeling reluctant to go this way... I 
would still be happy to merge it as-is and then work forward to the fluent-ish 
factory design (since @ansell has given a LGTM) and there is agreement that 
having fields not be `Optional`s is good in any case. @stain, would you like to 
see some checks against `null`-valued fields? I can certainly add those easily 
enough.


---

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

[GitHub] commons-rdf pull request #49: Cleanup for FindBugs and PMD warnings in -simp...

[ajs6f]

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/commons-rdf/pull/49#discussion_r168260775
  
--- Diff: 
commons-rdf-simple/src/main/java/org/apache/commons/rdf/simple/experimental/AbstractRDFParser.java
 ---
@@ -58,8 +60,12 @@
  */
 public abstract class AbstractRDFParser> 
implements RDFParser, Cloneable {
 
-public static final ThreadGroup threadGroup = new ThreadGroup("Commons 
RDF parsers");
-private static final ExecutorService threadpool = 
Executors.newCachedThreadPool(r -> new Thread(threadGroup, r));
+public static final AtomicInteger threadCount = new AtomicInteger();
+private static Thread newThread(Runnable r) {
--- End diff --

Because either FindBugs or PMD (can't remember) which called out 
`ThreadGroup` as not threadsafe, which is correct as far as I know. I am in 
_no_ way wedded to this change and if we can guarantee thread-safety from 
outside the class (or simply document it as not threadsafe) I would be happy to 
pull this change out.


---

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

[GitHub] commons-rdf issue #48: Cleanup in commons-rdf-rdf4j to close PMD and FindBug...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/48
  
@wikier I've got a triple of PRs here to clean up warnings, as we heard 
about last release. Is there a problem with merging them? Is there something I 
should do to help them merge-able? Thanks! 


---

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

[GitHub] commons-rdf issue #46: Add .DS_Store to .gitignore (Mac OS X system file)

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/46
  
Is there any problem with merging this? Is there anything I can do to move 
it along?


---

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

[GitHub] commons-rdf pull request #52: Adding convenient Dataset and DatasetGraph con...

[ajs6f]

GitHub user ajs6f opened a pull request:

https://github.com/apache/commons-rdf/pull/52

Adding convenient Dataset and DatasetGraph conversions

PR for COMMONSRDF-74.

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

$ git pull https://github.com/ajs6f/commons-rdf AddMoreJenaConversions

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

https://github.com/apache/commons-rdf/pull/52.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 #52


commit 0c9ae7e83f9253d5b9efc4b7ad8261c09e4f8e74
Author: ajs6f <ajs6f@...>
Date:   2018-01-29T18:12:36Z

Adding convenient Dataset and DatasetGraph conversions




---

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

Re: [VOTE] Release Apache Commons RDF 0.5.0 based on RC3

[ajs6f]

I have some PRs in now for some of these issues, which I mention merely as 
reassurance that they will get looked at.

ajs6f

> On Dec 21, 2017, at 1:45 PM, Jörg Schaible <joerg.schai...@gmx.de> wrote:
> 
> Hi Bruno,
> 
> Am Wed, 13 Dec 2017 09:53:35 + schrieb Bruno P. Kinoshita:
> 
> [snip]
> 
>> I went through the  FindBugs/PMD reports in each module, and found the
>> following warnings:
>> 
>> 
>> * main module:
>>- Double checked locking is not thread safe in Java. (saw it in
>>another part, not sure if it's really possibe to fix as we need
>>cannot create a model twice...)
>> 
>> * commons-df-api:
>>- Initialization of org.apache.commons.rdf.api.RDFSyntax accesses
>>class
>> org.apache.commons.rdf.api.W3CRDFSyntax, which isn't initialized yet
>> (this one seems easy to reproduce. Always returns null?)
>> 
>> * commons-rdf-simple:
>>- org.apache.commons.rdf.simple.DatasetGraphView.unionOrNamedGraph()
>>has Optional return type and returns explicit null (shouldn't it be
>>Optional.empty() or something similar?)
>> 
>> 
>> Are any of these blockers? The second one is the only one that if
>> confirmed seems annoying to users.
>> 
>> 
>> Everything looks OK, and I'm OK to vote to release in case others think
>> this release is not actually causing any of these warnings, and that we
>> should release as-is and fix it later.
> 
> Since it it a 0.5 release, we can address that later. So, do you vote?
> 
> 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

[GitHub] commons-rdf pull request #50: Cleanup for PMD warnings in -rdf-api

[ajs6f]

GitHub user ajs6f opened a pull request:

https://github.com/apache/commons-rdf/pull/50

Cleanup for PMD warnings in -rdf-api



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

$ git pull https://github.com/ajs6f/commons-rdf CleanupAPI

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

https://github.com/apache/commons-rdf/pull/50.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 #50


commit f998f5d3fac68fafe12586a9976d26e7a723cba1
Author: ajs6f <aj...@apache.org>
Date:   2017-12-14T17:53:39Z

Cleanup for PMD warnings in -rdf-api




---

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

[GitHub] commons-rdf pull request #49: Cleanup for FindBugs and PMD warnings in -simp...

[ajs6f]

GitHub user ajs6f opened a pull request:

https://github.com/apache/commons-rdf/pull/49

Cleanup for FindBugs and PMD warnings in -simple and -jena



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

$ git pull https://github.com/ajs6f/commons-rdf JenaSimpleCleanup

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

https://github.com/apache/commons-rdf/pull/49.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 #49


commit f1649e034a2623137434fcc2810f8802d3ee9434
Author: ajs6f <aj...@apache.org>
Date:   2017-12-14T17:37:25Z

Cleanup for FindBugs and PMD warnings in commons-rdf-simple and 
commons-rdf-jena




---

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

[GitHub] commons-rdf pull request #48: Cleanup in commons-rdf-rdf4j to close PMD and ...

[ajs6f]

GitHub user ajs6f opened a pull request:

https://github.com/apache/commons-rdf/pull/48

Cleanup in commons-rdf-rdf4j to close PMD and FindBugs warnings



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

$ git pull https://github.com/ajs6f/commons-rdf RDF4jCleanup

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

https://github.com/apache/commons-rdf/pull/48.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 #48


commit 37ab026c576c8841f378cc2376ca02c478567e84
Author: ajs6f <aj...@apache.org>
Date:   2017-12-14T17:06:03Z

Cleanup in commons-rdf-rdf4j to close PMD and FindBugs warnings




---

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

Re: [VOTE] Release Apache Commons RDF 0.5.0 based on RC3

[ajs6f]

 +1 (non-binding) for release

Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
2017-04-03T15:39:06-04:00)
Java version: 1.8.0_65, vendor: Oracle Corporation
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"

Nice healthy build with mvn clean install.

aj...@apache.org

> On Dec 12, 2017, at 9:31 AM, Aaron Coburn  wrote:
> 
>  +1 Release this package (non-binding)
> 
> Builds on OS X with Java 8
> 
> $ mvn -version
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 
> 2017-10-18T03:58:13-04:00)
> Maven home: /usr/local/Cellar/maven/3.5.2/libexec
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: US-ASCII
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
> 
> Checked site (build works for me with this command: $ mvn clean install 
> site:site)
> 
> Checked OSGi metadata, checked deployment in Apache Karaf 4.1.2
> 
> Checked that NOTICE and LICENSE files are contained in each binary artifact.
> 
> Thanks,
> Aaron Coburn
> acob...@apache.org
> 
> 
> On 12/7/17, 11:52 PM, "Sergio Fernández"  wrote:
> 
>Hi,
> 
>once we addressed most of the issues from RC1 and RC2, I'd like to propose
>to release Apache Commons RDF 0.5.0 based on RC.
> 
>Apache Commons RDF aims to provide a common Java API for RDF 1.1 graphs and
>datasets. API bindings in Commons RDF 0.5.0 include Apache Jena, Eclipse
>RDF4J, JSON-LD Java as well as a standalone implementation (simple).
> 
>Apache Commons RDF 0.5.0 RC3 is available for review at (r23441):
> 
>https://dist.apache.org/repos/dist/dev/commons/rdf/apache-
>commons-rdf-0.5.0-RC3/
> 
>The source code for this RC is available from git tagged as 0.5.0-RC3
>(commit e82eaa0b7d67f5a1afdf4cdecc19589fbe1654d6):
> 
>https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=commit;h=
>e82eaa0b7d67f5a1afdf4cdecc19589fbe1654d6
> 
>Mirrored at https://github.com/apache/commons-rdf/commit/
>e82eaa0b7d67f5a1afdf4cdecc19589fbe1654d6
> 
>This source release produces the following binary artifacts:
> 
>commons-rdf-parent-0.5.0
>commons-rdf-api-0.5.0
>commons-rdf-simple-0.5.0
>commons-rdf-jena-0.5.0
>commons-rdf-rdf4j-0.5.0
>commons-rdf-jsonld-java-0.5.0
>commons-rdf-integration-tests-0.5.0
> 
>The Maven Staging repository can be found at:
> 
>https://repository.apache.org/content/repositories/orgapachecommons-1295
> 
>containing the following artifacts:
> 
>commons-rdf-rdf4j-0.5.0.pom (SHA1: 
> 1cdc74b7205fa06531bd59e1ee24f1d15999ab1b)
>commons-rdf-rdf4j-0.5.0.jar (SHA1: 
> 265549b98b423c075f4a186dec76efb815c03649)
>commons-rdf-rdf4j-0.5.0-tests.jar (SHA1:
>9aab05dceefde27d79bc79f4b3c80daeeb01cb52)
>commons-rdf-rdf4j-0.5.0-javadoc.jar (SHA1:
>4254ac42dd569a45ab3b95c3d16cb8f47508039a)
>commons-rdf-rdf4j-0.5.0-test-sources.jar (SHA1:
>39eb4a6b10cafa4cfb87b4e48827006332ceaed3)
>commons-rdf-rdf4j-0.5.0-sources.jar (SHA1:
>f8a0ea29f31f501df05686abfd171f35fd39ed71)
>commons-rdf-api-0.5.0-sources.jar (SHA1:
>02735a136e206408f75507fbf27af1230a99f61b)
>commons-rdf-api-0.5.0.jar (SHA1: df2d4451dee5b311cb4f51ced214dfaab5838291)
>commons-rdf-api-0.5.0-tests.jar (SHA1:
>025730515d0e66043b6483710a9638e1f71ff917)
>commons-rdf-api-0.5.0-javadoc.jar (SHA1:
>3e15be3c7d018225aa6bafd91861474780c3ad8e)
>commons-rdf-api-0.5.0-test-sources.jar (SHA1:
>5f2554c926de52b5661f430b69c92dac2056a029)
>commons-rdf-api-0.5.0.pom (SHA1: cc3382c3a60d815a20bba1763933434f41d85598)
>commons-rdf-simple-0.5.0-tests.jar (SHA1:
>472e43e582ddcf1a7f06f9184f4bf26fad3b65fc)
>commons-rdf-simple-0.5.0.pom (SHA1:
>b5aa51f49cbbdb9f39fa70d8cf183f63ae0c3a6a)
>commons-rdf-simple-0.5.0-javadoc.jar (SHA1:
>87941fc168b6011fb003288eb392577fc4519be0)
>commons-rdf-simple-0.5.0-sources.jar (SHA1:
>7232c14775db216efc85a1a7fabb90c6a456950c)
>commons-rdf-simple-0.5.0.jar (SHA1:
>c6b5038624d860129e273538d18dd52c5adcfd70)
>commons-rdf-simple-0.5.0-test-sources.jar (SHA1:
>8028e8f20ebc465a6cd5a32fd9b8447eb4cf48dc)
>commons-rdf-parent-0.5.0-src.tar.gz (SHA1:
>5b3788cb6b647f3663839fd0737a5a85a75d19fa)
>commons-rdf-parent-0.5.0-src.zip (SHA1:
>519891322ed75f3ae4ef5cf7e8df60c65b797634)
>commons-rdf-parent-0.5.0.pom (SHA1:
>4186153db162b4382f73be1ce2ff97a98ee5d442)
>commons-rdf-parent-0.5.0-site.xml (SHA1:
>26fd1dc487f5f002d35841ba8dcc53704652d3b8)
>commons-rdf-integration-tests-0.5.0-test-sources.jar (SHA1:
>d7ad7ad0c09c3ae46d8da9c1ed989a9615369dcf)
>commons-rdf-integration-tests-0.5.0-tests.jar (SHA1:
>0db5cb5a32afcad51decae42c6a7d4dc7e62f15a)
>commons-rdf-integration-tests-0.5.0.pom (SHA1:
>

Re: [VOTE] Release Apache Commons RDF 0.5.0 based on RC2

[ajs6f]

Stian-- 

Just a quick technical question (really my own curiosity): I see you built with 
`mvn clean install -T1.0C` (explicitly calling out the thread count). Is that 
for reproducibility or some other reason?

ajs6f

> On Dec 6, 2017, at 7:59 AM, Stian Soiland-Reyes <st...@apache.org> wrote:
> 
> Good effort, Sergio! Sorry for late review.
> I guess you didn't get to many replies as there was confusion with the
> dist/svn revision.. :-(
> 
> 
> Sorry, my vote is -1 (binding)
> 
> .. as META-INF/LICENSE and META-INF/NOTICE are missing in the binary
> JARs in the maven repo.
> 
> (Not sure how I missed this before, is this caused by a change in
> commons-parent affecting submodules?)
> 
> 
> +1 gpg signatures dist & staging
> +1 dist svn (revision 23205 and 23227 are equal in this subtree)
> +1 git commit == tag ~= dist ~= staging  (except .gitignore / .travis.yml)
> -0 NOTICE has wrong Copyright year
> +1 builds with mvn clean install -T1.0C
> -1 META-INF/LICENSE and META-INF/NOTICE missing from JARs (except -api
> and -impl)
> 
> 
> Built with:
> 
> Apache Maven 3.3.9
> Maven home: /usr/share/maven
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.10.0-40-generic", arch: "amd64", family: "unix"
> 
> On 4 December 2017 at 11:13, Sergio Fernández <wik...@apache.org> wrote:
>> I'd like to bring up this vote, which is waiting for votes for two weeks :-/
>> 
>> 
>> On Nov 26, 2017 13:21, "Sergio Fernández" <wik...@apache.org> wrote:
>> 
>> I'd like to ask the Commons PMC to cast a, any, vote for this RC. Because
>> it's stuck. It's fine to get -1s, but at least something to move forward.
>> Thanks.
>> 
>> On Nov 22, 2017 17:52, "Sergio Fernández" <wik...@apache.org> wrote:
>> 
>>> Hi Oliver,
>>> 
>>> thanks for the feedback on RC2. Please, find my answers inline.
>>> 
>>> On Wed, Nov 22, 2017 at 1:25 PM, Oliver Heger <
>>> oliver.he...@oliver-heger.de> wrote:
>>>> 
>>>> [ERROR] Failed to execute goal
>>>> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-cli) on
>>>> project commons-rdf-parent: Error generating
>>>> maven-checkstyle-plugin:2.12.1:checkstyle-aggregate: Failed during
>>>> checkstyle configuration: cannot initialize module TreeWalker - Property
>>>> 'ignoreAnnotationCanonicalNames' in module VisibilityModifier does not
>>>> exist, please check the documentation -> [Help 1]
>>>> 
>>>> A problem with the version of the checkstyle plugin?
>>>> 
>>> 
>>> Maybe..., the version comes from Commons Parent. The issue is that I'm
>>> not able to reproduce the problem in Unix, neither in Linux nor OSX.
>>> 
>>> Some other notes:
>>>> * NOTICE has the wrong copyright year. I think this needs to be fixed.
>>>> 
>>> 
>>> Yeah, I reported that as https://issues.apache.org/j
>>> ira/browse/COMMONSRDF-69
>>> 
>>> 
>>>> * The project does not release binary artifacts. This is probably okay,
>>>> but unusual for Commons. It would be nice if you could add a binary
>>>> distribution - maybe for the 1.0 release.
>>>> 
>>> 
>>> Afterwards I updated the vote to include the binary release, too:
>>> 
>>> https://lists.apache.org/thread.html/23cf46d92c2afa191690edc
>>> a5ea76c0882c108c1a9dc1709a9d9ee52@%3Cdev.commons.apache.org%3E
>>> 
>>> Thanks.
>>> 
>>> 
>>> 
>>> Am 19.11.2017 um 23:08 schrieb Sergio Fernández:
>>>> Hi,
>>>> 
>>>> once we addressed most of the issues from RC1, I'd like to propose to
>>>> release Apache Commons RDF 0.5.0 based on RC2.
>>>> 
>>>> Apache Commons RDF aims to provide a common Java API for RDF 1.1 graphs
>>> and
>>>> datasets. API bindings in Commons RDF 0.5.0 include Apache Jena, Eclipse
>>>> RDF4J, JSON-LD Java as well as a standalone implementation (simple).
>>>> 
>>>> Apache Commons RDF 0.5.0 RC2 is available for review at (r23205):
>>>> 
>>>> https://dist.apache.org/repos/dist/dev/commons/rdf/apache-co
>>> mmons-rdf-0.5.0-RC2/
>>>> 
>>>> The source code for this RC is available from git tagged as 0.5.0-RC2
>>>> (commit 186df0c36981a30833879

Re: [VOTE] Release Apache Commons RDF 0.5.0 based on RC2

[ajs6f]

Non-binding +1:

I got a lovely clean build from 186df0c36981a308338792f02d93fc59776b0b7c using 
mvn clean install on

Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
2017-04-03T15:39:06-04:00)
Java version: 1.8.0_65, vendor: Oracle Corporation
OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"

NOTICE and LICENSE present, although the NOTICE has "Copyright 2015-2016", 
which I think we can update...

ajs6f

> On Nov 20, 2017, at 9:46 AM, Aaron Coburn <acob...@amherst.edu> wrote:
> 
> [X] +1 Release this package (non-binding)
> 
> Built on OS X with Maven 3.5.2 and Java 1.8.0_151
> 
> NOTICE and LICENSE files are present in the source release
> 
> Checked signatures
> 
> 
> Thanks for preparing this release,
> Aaron
> 
> 
> On 11/20/17, 7:27 AM, "Bruno P. Kinoshita" 
> <brunodepau...@yahoo.com.br.INVALID> wrote:
> 
>[ X ] +1 Release this package
> 
>Build passing from tag with
> 
>Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 
> 2017-10-18T20:58:13+13:00)
>Maven home: /opt/apache-maven-3.5.2
>Java version: 1.8.0_151, vendor: Oracle Corporation
>Java home: /usr/lib/jvm/java-8-oracle/jre
>Default locale: en_NZ, platform encoding: UTF-8
>OS name: "linux", version: "4.4.0-98-generic", arch: "amd64", family: 
> "unix"
> 
>No blocker issues in the site reports. Most seemed to be due to unused 
> imports and now newline imports. We can quickly fix these later or suppress 
> warnings in the reports if preferable.
> 
>Checked signatures of jars in Maven repository, all good.
> 
> 
>Thanks for preparing this new release.
> 
>Cheers,
>Bruno
> 
> 
> 
> 
>
>From: Sergio Fernández <wik...@apache.org>
>To: Commons Developers List <dev@commons.apache.org> 
>Sent: Monday, 20 November 2017 11:08 AM
>Subject: [VOTE] Release Apache Commons RDF 0.5.0 based on RC2
> 
> 
> 
>Hi,
> 
> 
>once we addressed most of the issues from RC1, I'd like to propose to
> 
>release Apache Commons RDF 0.5.0 based on RC2.
> 
> 
>Apache Commons RDF aims to provide a common Java API for RDF 1.1 graphs and
> 
>datasets. API bindings in Commons RDF 0.5.0 include Apache Jena, Eclipse
> 
>RDF4J, JSON-LD Java as well as a standalone implementation (simple).
> 
> 
>Apache Commons RDF 0.5.0 RC2 is available for review at (r23205):
> 
> 
>
> https://dist.apache.org/repos/dist/dev/commons/rdf/apache-commons-rdf-0.5.0-RC2/
> 
> 
>The source code for this RC is available from git tagged as 0.5.0-RC2
> 
>(commit 186df0c36981a308338792f02d93fc59776b0b7c):
> 
> 
>
> https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=commit;h=186df0c36981a308338792f02d93fc59776b0b7c
> 
> 
>Mirrored at
> 
>
> https://github.com/apache/commons-rdf/commit/186df0c36981a308338792f02d93fc59776b0b7c
> 
> 
>This source release produces the following binary artifacts:
> 
> 
>commons-rdf-parent-0.5.0
> 
>commons-rdf-api-0.5.0
> 
>commons-rdf-simple-0.5.0
> 
>commons-rdf-jena-0.5.0
> 
>commons-rdf-rdf4j-0.5.0
> 
>commons-rdf-jsonld-java-0.5.0
> 
>commons-rdf-integration-tests-0.5.0
> 
> 
>The Maven Staging repository can be found at:
> 
> 
>https://repository.apache.org/content/repositories/orgapachecommons-1293
> 
> 
>Please vote on releasing this release candidate as:
> 
> 
>Apache Commons RDF 0.5.0
> 
> 
>The vote is open for at least 72 hours/
> 
> 
>[ ] +1 Release this package
> 
>[ ] 0 I don't feel strongly about it, but don't object
> 
>[ ] -1 Do not release this package because...
> 
> 
>Anyone can participate in testing and voting, not just committers,
> 
>please feel free to try out the release candidate and provide your
> 
>votes!
> 
> 
>Thanks
> 
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org


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

[GitHub] commons-rdf pull request #46: Add .DS_Store to .gitignore (Mac OS X system f...

[ajs6f]

GitHub user ajs6f opened a pull request:

https://github.com/apache/commons-rdf/pull/46

Add .DS_Store to .gitignore (Mac OS X system file)



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

$ git pull https://github.com/ajs6f/commons-rdf patch-1

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

https://github.com/apache/commons-rdf/pull/46.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 #46


commit cdcafc6f45a555a4217a8f985fed813f3d1268cf
Author: A. Soroka <soro...@si.edu>
Date:   2017-11-20T16:43:13Z

Add .DS_Store to .gitignore (Mac OS X system file)




---

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

[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
@wikier My sense is that the right move here immediately is to merge this 
PR and then open a ticket to factor config (and a builder therefor) out of 
`AbstractRDFParser`. (A ticket I will be happy to work!)


---

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

[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
👍 


---

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

[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
I'd like to get @wikier an answer to his question. It sounds like we are 
_not_ comfortable merging this for `RC2` and he should go ahead without it, 
correct? 

If the consensus is that serializable config should be factored out of 
`AbstractRDFParser` (and I agree with that approach) than I think we should 
close `COMMONSRDF-49` and open a new ticket that is more exact (or edit 
`COMMONSRDF-49`) so that @ansell understands what to expect. I don't have the 
mojo in Commons RDF's Jira to do that.


---

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

[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
So the question is whether what is here now is a step forward.

I think it is, and I would want to do what is here whether or not we go 
onto a builder factoring. I intentionally did not add the marker interface to 
the type, and I think it's okay for the moment (especially as this is in the 
`experimental` package). I can and will do a builder refactoring, but I don't 
want to slow anyone down waiting for that.


---

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

[GitHub] commons-rdf issue #44: COMMONSRDF-70: Upgrade Jena version to 3.5.0

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/44
  
👍 


---

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

[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
My impression is that @afs objects to the current design, but I haven't 
heard feedback on [my 
suggestion](https://github.com/apache/commons-rdf/pull/43#issuecomment-341721718).


---

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

[GitHub] commons-rdf issue #44: COMMONSRDF-70: Upgrade Jena version to 3.5.0

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/44
  
Definitely can wait. There's no substantive API changes at stake, and 
anyone who wants to use Jena 3.5.0 w/ Commons RDF should be able to override 
the transitive dependency without untoward effect.


---

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

[GitHub] commons-rdf pull request #44: COMMONSRDF-70: Upgrade Jena version to 3.5.0

[ajs6f]

GitHub user ajs6f opened a pull request:

https://github.com/apache/commons-rdf/pull/44

COMMONSRDF-70: Upgrade Jena version to 3.5.0



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

$ git pull https://github.com/ajs6f/commons-rdf COMMONSRDF-70

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

https://github.com/apache/commons-rdf/pull/44.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 #44


commit 4f1e00c32174b34f08f23356dc7e479b44535204
Author: ajs6f <aj...@apache.org>
Date:   2017-11-03T14:49:35Z

COMMONSRDF-70: Upgrade Jena version to 3.5.0




---

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

[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
Well, it's hard for me to say, because I'm trying to predict the 
architecture of a system I am only beginning to design.  :(

@afs, @sebbASF, how about I break out a separate type for serializable 
config and a builder for it and we take that forward? It might be enough and if 
it isn't we can revisit the question then. I could leave `AbstractRDFParser` 
as-is, although I'd rather alter it, both for the reasons @kinow gave in Jira 
and if I break out a config-builder to indicate the preferred usage. 


---

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

[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/43
  
From my POV, serializing a parser is useful for very long or very large ETL 
when you may need to either pause and resume parsing (persisting the state of 
the task in between) or move parsing tasks from one portion of the execution 
environment to another. I'm not saying it's a no-brainer. :)

It may be better to have a subtype that is serializable but leave this type 
alone?


---

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

[GitHub] commons-rdf pull request #43: COMMONSRDF-49: Make AbstractRDFParser serializ...

[ajs6f]

GitHub user ajs6f opened a pull request:

https://github.com/apache/commons-rdf/pull/43

COMMONSRDF-49: Make AbstractRDFParser serializable

Very simple approach-- I just exposed the values of the fields internally 
and made the accessors keep producing `Optional`.  My understanding is that 
any modern JVM will hotspot all the `isPresent` and similar calls into `null` 
checks anyway, so there should be no performance implications.

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

$ git pull https://github.com/ajs6f/commons-rdf COMMONSRDF-49

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

https://github.com/apache/commons-rdf/pull/43.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 #43






---

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

[GitHub] commons-rdf issue #41: COMMONSRDF-65

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/41
  
No, there were no relative URIs being parsed into `Path`s in my code-- that 
string munging was to remove the `<` and `>` around the URI as retrieved from 
the RDF. But I'm a-okay with whatever gets a `toRealPath()` in there (because 
of the Mac symlinked `/tmp`) and avoids any confusion over leading slashes. I 
can see that I created more problems with Windows.

Sorry for mixing things up-- please always feel free to kick stuff back if 
you feel it's liable to mess up the history or confuse people-- I can always 
redo the PR!

All speed to 1.0!


---

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

[GitHub] commons-rdf pull request #41: COMMONSRDF-65

[ajs6f]

GitHub user ajs6f opened a pull request:

https://github.com/apache/commons-rdf/pull/41

COMMONSRDF-65

https://issues.apache.org/jira/browse/COMMONSRDF-65

Also a small fix for problems building on Mac, and includes 
https://github.com/apache/commons-rdf/pull/39/ to fix COMMONSRDF-62 (just so 
that I could build! :) )

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

$ git pull https://github.com/ajs6f/commons-rdf SmallThings

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

https://github.com/apache/commons-rdf/pull/41.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 #41


commit 29824463f4f7005a939a709089efa990152108ed
Author: ajs6f <aj...@apache.org>
Date:   2017-09-28T14:39:19Z

Upgrade to Jena 3.4.0

commit a774233f9143326b2d0d5b503fb72de63c8d49ad
Author: ajs6f <aj...@apache.org>
Date:   2017-09-28T15:31:40Z

Fixed bug in tests for Mac OS X filesystem behavior




---

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

[GitHub] commons-rdf issue #32: COMMONSRDF-55: Handle Jena's urn:x-arq:DefaultGraph a...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/32
  
I suppose I incline to (2) right now. The "magic" URIs are entirely 
Jena-specific, so ideally they appear as few places outside of Jena code itself 
as possible. On the other hand, `Quad.isDefaultGraph()` (the instance member, 
not the static function that takes a `Node`) seems like the most-encapsulated, 
best-segregated test.


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