commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Prepare commons RDF to JDK 9
Date Thu, 08 Mar 2018 18:01:08 GMT
On Thu, Mar 8, 2018 at 10:58 AM, Gilles <gilles@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 <gilles@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 <ajs6f@apache.org> wrote:
>>>>
>>>> > On Mar 8, 2018, at 8:33 AM, Gilles <gilles@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 ; ajs6f@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message