You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Kamila Molina (JIRA)" <ji...@apache.org> on 2018/03/04 17:56:00 UTC
[jira] [Comment Edited] (COMMONSSITE-103) GSOC: Apache Commons bug
bounty
[ https://issues.apache.org/jira/browse/COMMONSSITE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385260#comment-16385260 ]
Kamila Molina edited comment on COMMONSSITE-103 at 3/4/18 5:55 PM:
-------------------------------------------------------------------
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.
was (Author: kamila.molina97):
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/list.html?dev@commons.apache.org] using the subject tag [GSOC] and the commons component(s) they are intested in, e.g.
> {quote}
> To: dev@commons.apache.org
> 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)