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.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
