On Thu, Mar 8, 2018 at 10:58 AM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote: > >> 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. >> > > Did you see, a few lines above: "[...] assuming JDK 9+ [...]"? ;-) > > Related note: Java 9 is the target for compiling > "commons-rng-examples" (maven module) > in "Commons RNG" because one of the examples is composed of > JPMS modules (with "module-info" files) that depend on the > "official" artefacts (targeting Java 6) that declare an > "automatic module name" in the manifest. > Right now https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=blob;f=pom.xml;h=06cc58c19b79af5cdf2f3d29d9a743c8adb2b548;hb=HEAD shows Java 8 as the target. Are you taking about changing that to Java 9? I'll that choice to the Common RDF community but it seems that this would exclude a lot of users. Gary > > > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
