On Thu, Mar 8, 2018 at 10:29 AM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote: > >> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <aj...@apache.org> wrote: >> >> > 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 >>> >> >> >> 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. >> > > OK but, assuming JDK 9+, there must a way to create artefacts by > avoiding everything that breaks (hence the "profile" which all > components could use). > The end result would be a module whose access rights are enforced. > > 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 >> > > As I've wondered many times here: How do you ensure anything > by only writing this in the manifest? > > 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. >> > > 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. Gary > > Best regards, > Gilles > > > Gary >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
