> On Mar 8, 2018, at 8:33 AM, Gilles <gil...@harfang.homelinux.org> 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
