[
https://issues.apache.org/jira/browse/COMMONSSITE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385260#comment-16385260
]
Kamila Molina commented on COMMONSSITE-103:
-------------------------------------------
Hi [~ajs6f], [~erans], and [~stain],
Well, I see [commons-rdf|[https://github.com/apache/commons-rdf]] provides an
API for implementations of RDF frameworks. The idea would be use JPMS for each
module already in commons rdf.
The module system is thought not only for internal uses of Java, but also for
API developers or applications in general. This gets rid of the classpath and
uses a module-path, which solves some problems that classpath introduces,
specially at runtime.
About multi-version jars, I don't see it as a problem. The module system
doesn't store versions. Management tools such as maven in this case will handle
versioning. Of course, we can define versions as in the case of java-se@9, but
these work mostly as a tag to recognize the module, correct me if I am wrong
please.
We don't need to create a set of jars both for Java 8 and Java 9. If we just
move to Java 9, using JPMS those jars will be functional in older versions.
Java is characterized for backward compatibility.
The intent of my proposal will be to migrate commons-rdf to Java 9. In other
words, add module-info.java for each module in commons-rdf. With this, we
should to see which classes a user of commons-rdf will have access, and which
ones will be for internal purposes, for example.
> GSOC: Apache Commons bug bounty
> -------------------------------
>
> Key: COMMONSSITE-103
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-103
> Project: Commons All
> Issue Type: New Feature
> Reporter: Stian Soiland-Reyes
> Priority: Major
> Labels: commons, gsoc2018, library
>
> [Apache Commons|https://commons.apache.org/] is a project that manage a
> series of independent Java libraries called
> [components|https://commons.apache.org/components.html].
> Some of the perhaps most well known components include
> [commons-io|https://commons.apache.org/proper/commons-io/],
> [commons-lang|https://commons.apache.org/proper/commons-lang/],
> [commons-collections|https://commons.apache.org/proper/commons-collections/]
> and [commons-cli|https://commons.apache.org/proper/commons-cli/]
> But did you know that Commons is also managing some more specialized
> components like
> [commons-crypto|https://commons.apache.org/proper/commons-crypto/],
> [commons-numbers|https://commons.apache.org/proper/commons-numbers/],
> [commons-rng|https://commons.apache.org/proper/commons-rng/] and
> [commons-rdf|https://commons.apache.org/proper/commons-rdf/] ?
> The potential GSOC student will propose an idea to work with one or more
> chosen Apache Commons components to churn through any outstanding Jira
> issues, update for Java 8/9, improve web site, documentation or testing.
> As the appropriate GSOC mentor will depend slightly on which Commons
> component the student is interested in, prospective students are encouraged
> to engage early by subscribing and posting to
> [dev@commons|https://lists.apache.org/[email protected]]
> using the subject tag [GSOC] and the commons component(s) they are intested
> in, e.g.
> {quote}
> To: [email protected]
> Subject: [GSOC] [Crypto] Potential GSOC idea
> Hi, I am Alice, student at Foo university, and I am interested in GSOC for
> Apache Commons, in particular Commons Crypto as I have been quite involved in
> cryptography protocols over the years together with my friend Bob.
> What could be a good chunk of work to get started with? Perhaps adding
> support for rot13?
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
