Re: Modular version/edition of Apache Commons
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
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
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
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
> 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?
+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
> On May 19, 2018, at 5:34 AM, Emmanuel Bourg 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
+1 ajs6f > On May 18, 2018, at 5:50 PM, Bruno P. Kinoshita wrote: > > No objections from me. +1 > > Sent from Yahoo Mail on Android > > On Sat, 19 May 2018 at 9:24, Gary Gregory 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
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 wrote: > > On 22 April 2018 at 13:34, Ralph Goers 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 - 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?
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 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
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 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 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 >>>>> 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 - 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
> 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
> 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
> 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
Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9
> On Mar 8, 2018, at 12:09 PM, Gary Gregory wrote: > > That's all quite nice but the hard reality is that the tool chains out > there are simply not ready for JPMS, as I've painfully learned contributing > to Log4j 2. MR Jars, module-infos, all of that breaks Maven plugins and > tools left and right. So I do not see MR-jars as a viable options for any > Commons Components at this time. The best we can do ATM is play with > automatic module names in manifest files and look at what jdeps say about a > given component and see if we want to only depend on java.base or create > Maven modules to compartmentalize dependencies. > > Gary > "breaks Maven plugins and tools left and right" Yes. That's the point. That's perfectly fine. Kamila will find out which break, and how, and what options we have to deal with them, and when we might need to go upstream and come back, and she will document that, and she will do what work can be done now on those problems. If Commons RDF does not release MR JARs as part of the GSoC project, but we do understand specifically and in detail why and what the blockers are, the project will have been a success. With respect, I think you are now objecting to a project that hasn't actually been proposed, for which success would be releasing MR JARs. _That is not what is being proposed._ ajs6f - 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
> 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
Perhaps ? ajs6f > On Feb 23, 2018, at 12:12 PM, Gary Gregory wrote: > > On Fri, Feb 23, 2018 at 10:05 AM, Gary Gregory > wrote: > >> >> >> On Fri, Feb 23, 2018 at 10:04 AM, Gary Gregory >> wrote: >> >>> >>> >>> On Fri, Feb 23, 2018 at 7:03 AM, Matt Benson wrote: >>> >>>> On Feb 23, 2018 4:26 AM, "sebb" wrote: >>>> >>>> On 23 February 2018 at 00:41, Gary Gregory >>>> wrote: >>>>> On Thu, Feb 22, 2018 at 4:27 PM, sebb wrote: >>>>> >>>>>> On 22 February 2018 at 23:15, Gary Gregory >>>> wrote: >>>>>>> On Thu, Feb 22, 2018 at 4:11 PM, sebb wrote: >>>>>>> >>>>>>>> On 22 February 2018 at 22:27, Gary Gregory >>>> >>>>>> 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).toCharArray(); >>>} >>> >>>@Override >>>public String toCaseString(final String source, final Locale >>> locale) { >>>return source.toUpperCase(locale); >>>
[GitHub] commons-rdf pull request #49: Cleanup for FindBugs and PMD warnings in -simp...
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
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
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...
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...
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)
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...
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 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
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 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
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 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...
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 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 ...
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 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
+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: >dc8b7754e2069b8c19c507a59a665ba12fd60007) >
Re: [VOTE] Release Apache Commons RDF 0.5.0 based on RC2
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 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 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" 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" 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 186df0c36981a308338792f02d93fc59776b0b7c): >>>> >>>
Re: [VOTE] Release Apache Commons RDF 0.5.0 based on RC2
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 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" > 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 >To: Commons Developers List >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...
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 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
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
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
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
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
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
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
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
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 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
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
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...
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
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
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 Date: 2017-09-28T14:39:19Z Upgrade to Jena 3.4.0 commit a774233f9143326b2d0d5b503fb72de63c8d49ad Author: ajs6f 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...
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